Re: [PATCH 3/3] block: fail on open when file size is unaligned to request_alignment

[Eric Blake <eblake@redhat.com>]

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