From owner-svn-src-all@FreeBSD.ORG Tue Dec 7 22:31:32 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB1201065674; Tue, 7 Dec 2010 22:31:32 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 389608FC13; Tue, 7 Dec 2010 22:31:31 +0000 (UTC) Received: by qyk36 with SMTP id 36so437749qyk.13 for ; Tue, 07 Dec 2010 14:31:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=gM3xcQf50/idnK5RS8caS+E37qu/t8rjq/Xp+jPQu5o=; b=aeFSF65BTkN14vdYh1cPOWBdmLS07JHzykd3InLiJcosXQi+lTQPyI/jq9N8GQ0MwK kdD+i91TcGIH1rn1B6H+TAjDgHsUE0RZmmeMGlxEfpuXKWIgrVtaIJzD95mCHlWxdEEh 1dD0wC9kqh/K+a8r/U4eajVQwrsLGlW8bT/qE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=G8+THg3GEoyr7cvVE9KEGpdg0F/pWA3NWow2rMXBR2f2OtOXU5PUfcjjTPOlNDDZWL PkzdDuVfMbKTCGzc3CgBMRmCOMr8lZYUnhoXusSPF878MNeq5gpZukRllJvbJvUToztU urCaHupuwTRRRSdf0VGRHWk+bCnJV/wHVtyZY= Received: by 10.229.79.135 with SMTP id p7mr6188498qck.85.1291761090781; Tue, 07 Dec 2010 14:31:30 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.231.143 with HTTP; Tue, 7 Dec 2010 14:30:49 -0800 (PST) In-Reply-To: <20101207113152.GG1700@garage.freebsd.pl> References: <201012061218.oB6CI3oW032770@svn.freebsd.org> <20101206184453.GA1936@garage.freebsd.pl> <20101206192238.GB1936@garage.freebsd.pl> <20101206195327.GD1936@garage.freebsd.pl> <20101207102104.GD1700@garage.freebsd.pl> <20101207113152.GG1700@garage.freebsd.pl> From: Ivan Voras Date: Tue, 7 Dec 2010 23:30:49 +0100 X-Google-Sender-Auth: Zq6vzr-0L312nJnbnIPEHgs2XCs Message-ID: To: Pawel Jakub Dawidek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2010 22:31:33 -0000 On 7 December 2010 12:31, Pawel Jakub Dawidek wrote: > On Tue, Dec 07, 2010 at 12:25:28PM +0100, Ivan Voras wrote: >> On 7 December 2010 11:21, Pawel Jakub Dawidek wrote: >> >> > PS. Do you know your change breaks all current ZFS installation if >> > stripesize is defined for a provider? >> > >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0# zpool create tank ada0 >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0(upgrade FreeBSD so that ada0 now reports 4= kB stripesize) >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0# zpool import tank >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0cannot import 'tank': invalid vdev configur= ation >> >> Actually I did test the patch and, similar to the Solaris people, >> found that ZFS records ashift in metadata and uses the recorded one >> instead of hardcoded / detected one. What you found here really >> shouldn't happen. Are you sure only stripesize was increased in your >> case, not sectorsize? > > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (pp->stripesize > pp->sectorsize) > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*ashift =3D highbi= t(MIN(pp->stripesize, SPA_MAXBLOCKSIZE)) - 1; > =C2=A0 =C2=A0 =C2=A0 =C2=A0else > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*ashift =3D highbi= t(MAX(pp->sectorsize, SPA_MINBLOCKSIZE)) - 1; > > If stripesize will start to be 4096, the ashift will change. > > Not sure what you test was, but it only works the other way around - > create pool with 4kB ashift and import it when ashift is 512 bytes. My test was flawed, it made me conclude that ashift from metadata would be used in this case (this case is actually one of the more trivial ones - vdev created with ashift=3D9 used on device which is capable of ashift=3D9 but advertises ashift=3D12). In case it would be useful in the future, this is blocked in vdev_open(): http://fxr.watson.org/fxr/source/cddl/contrib/opensolaris/uts/common/fs/zfs= /vdev.c#L1075 I think that to solve this edge case properly, ZFS would have to know that both ashift values are "valid" for the device, i.e. basically it would at this point need to somehow know about our sectorsize and stripesize, not just ashift. OpenSolaris lists mention that pools can be created from devices with different ashift values, which is good news.