From owner-svn-src-all@FreeBSD.ORG Mon Dec 6 20:19:11 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 2D9DA1065672; Mon, 6 Dec 2010 20:19:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EFBE78FC13; Mon, 6 Dec 2010 20:19:10 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 91D6346B65; Mon, 6 Dec 2010 15:19:10 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A66898A009; Mon, 6 Dec 2010 15:19:09 -0500 (EST) From: John Baldwin To: Pawel Jakub Dawidek Date: Mon, 6 Dec 2010 15:18:49 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <201012061218.oB6CI3oW032770@svn.freebsd.org> <20101206195327.GD1936@garage.freebsd.pl> In-Reply-To: <20101206195327.GD1936@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201012061518.49835.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 06 Dec 2010 15:19:09 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Ivan Voras 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: Mon, 06 Dec 2010 20:19:11 -0000 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? For 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 instead 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, etc. -- John Baldwin