From owner-freebsd-fs@FreeBSD.ORG Wed Jul 10 20:37:54 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EF3286B7; Wed, 10 Jul 2013 20:37:54 +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 1FA4D1A84; Wed, 10 Jul 2013 20:37:53 +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 md50004911799.msg; Wed, 10 Jul 2013 21:37:51 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 10 Jul 2013 21:37:51 +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: 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> <7BB4167807A4434A9CD5FB0F1600439F@multiplay.co.uk> <00205B20-742F-44F6-B538-3B809D8BC03F@FreeBSD.org> Subject: Re: Make ZFS use the physical sector size when computing initial ashift Date: Wed, 10 Jul 2013 21:38:07 +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-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 20:37:55 -0000 ----- Original Message ----- From: "Justin T. Gibbs" ... >>> > 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. > > I'm not sure I follow. logical_ashift is available in our latest code, as is the > physical_ashift. But even without the logical_ashift, why doesn't the zio > pipeline properly thunk zio_phys_read() access based on the configured ashift? When I looked at it, which was a long time ago now so please excuse me if I'm a little rusty on the details, zio_phys_read() was working more luck than judgement as the offsets passed in where calculated from a valid start + increment based on the size of a structure within vdev_label_offset() with no ashift logic applied that I cound find. The result was pools created with large ashift's where unstable when I tested. 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.