Date: Thu, 18 Jul 2013 21:22:50 +0100 From: "Steven Hartland" <smh@freebsd.org> To: <d@delphij.net> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Xin LI <delphij@FreeBSD.org> Subject: Re: svn commit: r253441 - in head: cddl/contrib/opensolaris/cmd/zpool sys/cddl/contrib/opensolaris/uts/common/fs/zfs Message-ID: <A8D812B7250E4072BFCDACF5EA644674@multiplay.co.uk> References: <201307180022.r6I0MgeS094364@svn.freebsd.org> <251C370CF0FF4EE686D571A1235D4C90@multiplay.co.uk> <51E73BCA.3030404@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "Xin Li" <delphij@delphij.net> > -----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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A8D812B7250E4072BFCDACF5EA644674>