From owner-svn-src-head@FreeBSD.ORG Mon Dec 6 20:32:24 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28EF5106564A; Mon, 6 Dec 2010 20:32:24 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 415E98FC16; Mon, 6 Dec 2010 20:32:22 +0000 (UTC) Received: by vws9 with SMTP id 9so5089924vws.13 for ; Mon, 06 Dec 2010 12:32:21 -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=86PCksk45pXsZIGNQv3jGSy0FeOLVE7JouQIc+Qk2MA=; b=JgApZiOOjT6wlOcXXT9GsChAmQPK4tklMSRcPQyIbYOMZHkyaTF/MMQzMBjAbToSww A6xdcan4gnvcLjPO6r5OXCeVZEq9R8G8eofM8ESJTfzR5JEfN1LyYlKDB2N07OEwo58v zqCG+lPtkQnSp/j1C6xAigB7qVetHoXI1Zci8= 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=LGwIRPaJM1Aprn9hmHQWR7a7hV4CvoyWGvsZbfWKLNDlIXmG5VRCK3dMo8gwNGlHo1 fuioFdYY6YOhOM7vBpPfHWtnCSLtmIdWTJz+rXo8lmMjKiprS2F8sqF+HAGxIpSY0itZ Qv2dQEkFdvJi4GFMP2tdybtVeJMKtFVdtTrDg= Received: by 10.229.82.70 with SMTP id a6mr4949580qcl.9.1291667540173; Mon, 06 Dec 2010 12:32:20 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.231.143 with HTTP; Mon, 6 Dec 2010 12:31:39 -0800 (PST) In-Reply-To: <201012061518.49835.jhb@freebsd.org> References: <201012061218.oB6CI3oW032770@svn.freebsd.org> <20101206195327.GD1936@garage.freebsd.pl> <201012061518.49835.jhb@freebsd.org> From: Ivan Voras Date: Mon, 6 Dec 2010 21:31:39 +0100 X-Google-Sender-Auth: OEQE7951TXo9WJy_Z_hJmPzKt6c Message-ID: To: John Baldwin 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, Pawel Jakub Dawidek Subject: Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 20:32:24 -0000 On 6 December 2010 21:18, John Baldwin wrote: > On Monday, December 06, 2010 2:53:27 pm Pawel Jakub Dawidek wrote: >> On Mon, Dec 06, 2010 at 08:35:36PM +0100, Ivan Voras wrote: >> > Please persuade me on technical grounds why ashift, a property >> > intended for address alignment, should not be set in this way. If your >> > answer is "I don't know but you are still wrong because I say so" I >> > will respect it and back it out but only until I/we discuss the >> > question with upstream ZFS developers. >> >> No. You persuade me why changing ashift in ZFS, which, as the comment >> clearly states is "device's minimum transfer size" is better and not >> hackish than presenting the disk with properly configured sector size. >> This can not only affect disks that still use 512 bytes sectors, but >> doesn't fix the problem at all. It just works around the problem in ZFS >> when configured on top of raw disks. >> >> What about other file systems? What about other GEOM classes? GELI is >> great example here, as people use ZFS on top of GELI alot. GELI >> integrity verification works in a way that not reporting disk sector >> size properly will have huge negative performance impact. ZFS' ashift >> won't change that. > > I am mostly on your side here, but I wonder if GELI shouldn't prefer the > stripesize anyway? =C2=A0For example, if you ran GELI on top of RAID-5 I = imagine it > would be far more performant for it to use stripe-size logical blocks ins= tead > of individual sectors for the underlying media. > > The RAID-5 argument also suggests that other filesystems should probably > prefer stripe sizes to physical sector sizes when picking block sizes, et= c. For what it's worth, apparently linux has the concept of "physical" and "logical" sector sizes (possibly in addition to "stripe size"), with physical being 4096 and logical 512, for example: # hdparm -I /dev/sde | grep size Logical Sector size: 512 bytes Physical Sector size: 4096 bytes device size with M =3D 1024*1024: 1430799 MBytes device size with M =3D 1000*1000: 1500301 MBytes (1500 GB)