Invalid ashift increase allowed by r253441

[Xin Li]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi, Steven,

On 7/30/13 5:16 PM, Steven Hartland wrote:
[...]
>> 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?

No, GEOM does not allow this.

>> 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.

I think your analysis is correct.  However, in my opinion, ZFS should
make sure that the access is aligned when it issues the operation to
the underlying GEOM provider, and banning import of pools with larger
ashift is just papering problems out, which is not desirable.

[...]
> I suspect this came about because of changes to how ashift was
> being reported / faked, very simular to the patches many of us have
> for FreeBSD.
> 
> If I'm correct this strengthens my view that this change is
> incorrect, as what was trying to be done was support for faked
> sector size on devices such as SSD's and HD's which report and
> importantly support 512b sectors even if they are reported to ZFS
> as 4k. This is very different from supporting a device which ONLY
> supports a large sector size and hence smaller accesses would fail
> which this change allows.

Well, we actually need to answer two questions, not just one:

a) should a pool be importable when ashift increases?

I think the answer is "Yes" here, which is done by r253441.  No, this
is not optimal, but it does not really hurt anything if we make ZFS do
the right thing, which is the second issue:

b) should ZFS access smaller block when ashift demands larger ones?

My answer would be "No" and in my opinion, this is the real underlying
issue that needs to be addressed -- I would not really mind if we
revert r253441 for now, but it would make us diverge further from
upstream and, on the other hand, doesn't really buy us anything and
papers the real issue out.

Cheers,
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJR+e3fAAoJEG80Jeu8UPuzkdYIAIUCjLGT+9t/qn3r8/7Lce7f
zU85TuPnANnfNoD3xxq2rLqrLu+23w4fHdlzPTWG2GGdHS1s5VeVt3zl0SO3uhuW
43l+ecJL8Kd3cl2n1PTiHPwENnebm6OOPg8S7RDdxSJUX/Jvz5Of9UJRPtuh6J9p
s/DwLDvPMGHVEVuZ0XkJbxvz/NkqMy08iizLBI3MJnZ61z4OjmFlhCJ1UiZiBPSV
SU7zKRtjU221RHhSV0xm21fD+b5fRjBOgMS88uZPF27VI/NT0NfpAgX9fMtBzcSw
faQSfEExb00NBiVsDooaZPrwuQXuvtHfaDK3y0w4JR/3kwV1wA9TJU5d1cVDLXY=
=7R36
-----END PGP SIGNATURE-----