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

[Vladimir Sementsov-Ogievskiy]

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