Invalid ashift increase allowed by r253441 (was: Re: svn commit: r253441 ...)

Steven Hartland killing at multiplay.co.uk
Wed Jul 31 00:15:34 UTC 2013


----- Original Message ----- 
From: "Steven Hartland" <smh at freebsd.org>
> ----- 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.

Just wanted to chase up on this one to see if I'm barking up the wrong
tree or if this could cause serious breakage like I think it could.

Looking at the illumos issue and commit for this:
https://www.illumos.org/issues/2671
https://github.com/illumos/illumos-gate/commit/2384d9f8fcca0a7ef8b3ae674d94df82832c0fce

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.

Thoughts?

    Regards
    Steve

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster at multiplay.co.uk.



More information about the zfs-devel mailing list