Am 08.01.2020 um 20:46 hat Nir Soffer geschrieben: > On Wed, Jan 8, 2020 at 7:52 PM Alberto Garcia <be...@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