On 3/12/20 4:06 AM, Vladimir Sementsov-Ogievskiy wrote:
So the real solution would probably... Be to align the file size up to
the alignment?
Or to bite the bullet and finally implement byte-accurate size
everywhere (instead of our current insistence on rounding size up to
512-byte multiples). If we have to deal with unaligned tails anyways,
it's better to make the code universally applicable whether that
unaligned tail is to 512 or to 4k, than to have it work for 512 but to
fail for 4k.
But how it helps with the problem of files unaligned to
request_alignment defined by driver?
In a byte-accurate world, no driver should ever report an unaligned
size. If the driver is capable of sub-sector sizes, it is also capable
of sub-sector I/O and should state as such in its request_alignment.
The block layer then takes care of ensuring that any access of the final
unaligned sector or 4k region either leaves the bytes past EOF alone, or
at most reads those bytes as zeroes, and maybe permits attempts to write
no-op zeroes to those bytes, but gracefully forbids attempts to store
data that would cause the file to be resized.
But that's the ideal world, and it requires a lot of code auditing to
get there. It probably won't happen in time for the 5.0 release.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
