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>