From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 10 19:41:50 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 200F2DF7; Wed, 10 Jul 2013 19:41:50 +0000 (UTC) (envelope-from prvs=1903808b5b=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 34B9A1796; Wed, 10 Jul 2013 19:41:48 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50004911185.msg; Wed, 10 Jul 2013 20:41:47 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 10 Jul 2013 20:41:47 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1903808b5b=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <7BB4167807A4434A9CD5FB0F1600439F@multiplay.co.uk> From: "Steven Hartland" To: "Justin T. Gibbs" References: <86zjtupz3r.fsf@nine.des.no> <51DD9801.4090808@delphij.net> <2B9367B6-8759-45C9-B120-9D00A381228F@FreeBSD.org> <97E5A0A8DFBF4F75AAE8EDEFDF849EB0@multiplay.co.uk> <0A3A05F7-7859-4285-B15A-5E7DDB751062@FreeBSD.org> Subject: Re: Make ZFS use the physical sector size when computing initial ashift Date: Wed, 10 Jul 2013 20:42:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-fs@freebsd.org, =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , d@delphij.net, ivoras@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 19:41:50 -0000 ----- Original Message ----- From: "Justin T. Gibbs" > On Jul 10, 2013, at 1:06 PM, "Steven Hartland" wrote: >> ----- Original Message ----- From: "Justin T. Gibbs" >>> I'm sure lots of folks have "some solution" to this. Here is an >>> old version of what we use at Spectra: >>> http://people.freebsd.org/~gibbs/zfs_patches/zfs_auto_ashift.diff >>> The above patch is missing some cleanup that was motivated by my >>> discussions with George Wilson about this change in April. I'll >>> dig that up later tonight. Even if you don't read the full diff, >>> please read the included checkin comment since it explains the >>> motivation behind this particular solution. >>> >>> This is on my list of things to upstream in the next week or so after >>> I add logic to the userspace tools to report whether or not the >>> TLVs in a pool are using an optimal allocation size. This is only >>> possible if you actually make ZFS fully aware of logical, physical, >>> and the configured allocation size. All of the other patches I've seen >>> just treat physical as logical. >> >> Reading through your patch it seems that your logical_ashift equates to >> the current ashift values which for geom devices is based off sectorsize >> and your physical_ashift is based stripesize. >> >> This is almost identical to the approach I used adding a "desired ashift", >> which equates to your physical_ashift, along side the standard ashift >> i.e. required aka logical_ashift value :) > > Yes, the approaches are similar. Our current version records the logical > access size in the vdev structure too, which might relate to the issue > below. > > > One issue I did spot in your patch is that you currently expose > > zfs_max_auto_ashift as a sysctl but don't clamp its value which would > > cause problems should a user configure values > 13. > > I would expect the zio pipeline to simply insert an ashift aligned thunking > buffer for these operations, but I haven't tried going past an ashift of 13 in > my tests. If it is an issue, it seems the restriction should be based on > logical access size, not optimal access size. Yes with your methodology you'll only see the issue if zfs_max_auto_ashift and physical_ashift are both > 13, but this can be the case for example on a RAID controller with large stripsize. Looking back at my old patch it too suffers from the same issue along with the current code base, but that would only happen if logical sector size resulted in an ashift > 13 which is going to be much less common ;-) Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.