Re: [PATCH 1/3] qcow2: Require that the virtual size is a multiple of the sector size

[Kevin Wolf <kwolf@redhat.com>]

Am 08.01.2020 um 20:46 hat Nir Soffer geschrieben:
> On Wed, Jan 8, 2020 at 7:52 PM Alberto Garcia <berto@igalia.com> wrote:
> >
> > The qcow2 header specifies the virtual size of the image in bytes, but
> > BlockDriverState stores it as a number of 512-byte sectors.
> >
> > If the user tries to create an image with a size that is not a
> > multiple of the sector size then this is fixed on creation by
> > silently rounding the image size up (see commit c2eb918e32).
> > qcow2_co_truncate() is more strict and returns an error instead.
> >
> > However when an image is opened the virtual size is rounded down,
> > which means that trying to access the last few advertised bytes will
> > result in an error. As seen above QEMU cannot create such images and
> > there's no good use case that would require us to try to handle them
> > so let's just treat them as unsupported.

I still hope that we'll convert bs->total_sectors to something based on
bytes so we can actually handle byte-granularity image sizes, but for
the time being, I guess this fix makes sense (though we don't have the
check in other drivers which have the same problem).

> Making error impossible is best.
> 
> Can we require multiple of 4k to avoid unaligned read/write at the end
> of an image aligned to 512 bytes on storage with 4k sector size?

A qcow2 image should be able to provide an image for any disk the user
wants to expose to the guest, and 4k alignment would certainly limit
that ability. I suspect that if CHS geometry matters for a guest, not
having a 4k aligned size is actually quite likely.

Kevin