From owner-svn-src-all@FreeBSD.ORG Thu Jul 18 20:22:31 2013 Return-Path: Delivered-To: svn-src-all@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 D1B0A306; Thu, 18 Jul 2013 20:22:31 +0000 (UTC) (envelope-from smh@freebsd.org) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 9948D786; Thu, 18 Jul 2013 20:22:31 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id E54FB20E7088C; Thu, 18 Jul 2013 20:22:23 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-2.2 required=8.0 tests=ALL_TRUSTED,AWL,BAYES_00, STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPA id 4E19820E70847; Thu, 18 Jul 2013 20:22:22 +0000 (UTC) Message-ID: From: "Steven Hartland" To: References: <201307180022.r6I0MgeS094364@svn.freebsd.org> <251C370CF0FF4EE686D571A1235D4C90@multiplay.co.uk> <51E73BCA.3030404@delphij.net> Subject: Re: svn commit: r253441 - in head: cddl/contrib/opensolaris/cmd/zpool sys/cddl/contrib/opensolaris/uts/common/fs/zfs Date: Thu, 18 Jul 2013 21:22:50 +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: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Xin LI X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 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: Thu, 18 Jul 2013 20:22:31 -0000 ----- Original Message ----- From: "Xin Li" > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 07/17/13 17:34, Steven Hartland wrote: >> This is an interesting change, could this not cause serious issues >> when we try to read / write to a disk with an incompatible block >> size? > > No, it's safe to use larger ashift to access pool formatted with > smaller ashift, it's not optimal but better than marking the pool > FALUTERED, and yes, the operator still have to recreate the pool if > performance is a concern. Maybe I'm missing something but if the device is truely using a larger sectorsize than that which the zpool was created with then surely attempts to address it will fail in g_io_check when bio_offset is not a factor of sectorsize? For example on a native 4k sectorsize disk its not possible to directly access the bytes at offset 512 instead you would need to read offset 0 and scan in 512 bytes to the returned data block. I didn't think geom / zfs dealt with this case? The only case I can see this happening is if an old 512b sectorsize disk was dd'ed to a new 4k sectorsize one but thats effectively what this change is allowing. Regards Steve