svn commit: r253441 - in head: cddl/contrib/opensolaris/cmd/zpool sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Steven Hartland]

----- Original Message ----- 
From: "Xin Li" <delphij at 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