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

[Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>]

11.03.2020 15:29, Eric Blake wrote:
> On 3/11/20 6:06 AM, Max Reitz wrote:
>> On 30.01.20 16:22, Vladimir Sementsov-Ogievskiy wrote:
>>> Prior to the commit the following command lead to crash:
>>>
>>>    ./qemu-io --image-opts -c 'write 0 512' \
>>>    driver=blkdebug,align=4096,image.driver=null-co,image.size=512
>>>
>>> It failes on assertion in bdrv_aligned_pwritev:
>>>    "end_sector <= bs->total_sectors || child->perm & BLK_PERM_RESIZE"
>>>
>>> The problem is obvious: 512 is aligned to 4096 and becomes larger than
>>> file size. And the core bad thing is that file size is unaligned to
>>> request_alignment.
>>>
>>> Let's catch such case on bdrv_open_driver and fail.
>>
>> I think we had a discussion on this before, but I can’t find it right
>> now.  (Although I think that had more to do with something in the
>> file-posix driver, because it wasn’t limited to alignments above 512.)
>>
>> In any case, the file itself is totally valid.  Most importantly, qcow2
>> will regularly create files with unaligned file lengths.
>>
>> So let me create a qcow2 image on a 4k-aligned device:
>>
>> $ truncate 512M fs.img
>> $ sudo losetup -f --show -b 4096 fs.img
>> /dev/loop0
>> $ sudo mkfs.ext4 /dev/loop0
>> [...]
>> $ sudo mount /dev/loop0 /mnt/tmp
>>
>> $ sudo ./qemu-img create -f qcow2 /mnt/tmp/foo.qcow2 64M
>> Formatting '/mnt/tmp/foo.qcow2', fmt=qcow2 size=67108864
>> cluster_size=65536 lazy_refcounts=off refcount_bits=16
>> $ sudo ./qemu-io -t none -c quit /mnt/tmp/foo.qcow2
>> qemu-io: can't open device /mnt/tmp/foo.qcow2: File size is unaligned to
>> request alignment
>>
>> Which is too bad.
>>
>> 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?

-- 
Best regards,
Vladimir