Bug 1994266

Hi,

The problem is exactly what the error message says.  We create the target image with the same size as the source, i.e. a non-4k-aligned size, but writing to it would mean we would have to change its size.

Is this really a bug?  Do we want qemu-img convert to create an image of a different size than the source?

The error message is also clear enough that I think it’s clear to users what to do to work around this, namely to first extend the source image to be aligned to 4k.


OTOH, changing this behavior seems really simple, it could be a one-liner, like:

diff --git a/qemu-img.c b/qemu-img.c
index 908fd0cce5..c5308dcdad 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -2622,6 +2622,7 @@ static int img_convert(int argc, char **argv)
     s.target_is_new = !skip_create;
 
     flags = s.min_sparse ? (BDRV_O_RDWR | BDRV_O_UNMAP) : BDRV_O_RDWR;
+    flags |= BDRV_O_RESIZE;
     ret = bdrv_parse_cache_mode(cache, &flags, &writethrough);
     if (ret < 0) {
         error_report("Invalid cache option: %s", cache);



And basically that change tells the story: We would need to allow opening the target image to lead to it being resized, but naively img_convert() doesn’t want the target image to be resized after it’s been created.

I think I’ll send an RFC upstream and see what others think.

Hanna

(In reply to Hanna Reitz from comment #1)
> Hi,
> 
> The problem is exactly what the error message says.  We create the target
> image with the same size as the source, i.e. a non-4k-aligned size, but
> writing to it would mean we would have to change its size.
> 
> Is this really a bug?  Do we want qemu-img convert to create an image of a
> different size than the source?
The case is from bug 1649788, and you could check the reproduced steps via https://bugzilla.redhat.com/show_bug.cgi?id=1649788#c32. And user can convert success without any error message after this bug was fixed.
                                                                                                                                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^       
The only difference: The host sector size is 512 of bug 1649788, while for this bug the host sector size is 4k.


Best,
Tingting

(In reply to Tingting Mao from comment #2)
> (In reply to Hanna Reitz from comment #1)
> > Hi,
> > 
> > The problem is exactly what the error message says.  We create the target
> > image with the same size as the source, i.e. a non-4k-aligned size, but
> > writing to it would mean we would have to change its size.
> > 
> > Is this really a bug?  Do we want qemu-img convert to create an image of a
> > different size than the source?
> The case is from bug 1649788, and you could check the reproduced steps via
> https://bugzilla.redhat.com/show_bug.cgi?id=1649788#c32. And user can
> convert success without any error message after this bug was fixed.
>                                                                             
> ^^^^^^^^^^^^^^^^^^^^^^^^^       
Change bug 1649788 to bug 1678979.

> The only difference: The host sector size is 512 of bug 1649788, while for
> this bug the host sector size is 4k.
Change bug 1649788 to bug 1678979.

Hm, OK.  I think that bug is still quite different, because a failed assertion is worse than a clean error message that implies what to do to work around the problem.

I’ve sent a patch upstream: https://lists.nongnu.org/archive/html/qemu-block/2021-08/msg00280.html

(In reply to Hanna Reitz from comment #5)
> I’ve sent a patch upstream:
> https://lists.nongnu.org/archive/html/qemu-block/2021-08/msg00280.html

Agree. What I would like to say is that converting from the image with unaligned size to 512 bytes works fine, but converting from the image with unaligned size to 4k bytes fails with error messages.

Note:
AFAIK, the machines with sector unit size of 512 bytes are mostly used by users. But there are also some users using the machines with the sector unit size of 4k bytes.

Sorry for forgetting about this BZ; the patch from comment 4 has been merged as a1c62436a4f053766892355da0ca35c5df19fc22, which became part of the 6.2.0 release.

Hi Tingting,

Please have a test with latest build.

Thanks.

Tried in latest qemu, there is no the bug.


Tested with:
qemu-kvm-6.2.0-7.el9
kernel-5.14.0-47.el9.x86_64


Steps:
# truncate -s 18432 test.img
# qemu-img convert -f raw -O raw -p -t none -T none test.img tgt.img 
    (100.00/100%)

Note for host disk info:
# fdisk -l
Disk /dev/sda: 558.38 GiB, 599550590976 bytes, 146374656 sectors
Disk model: PERC H730P Adp  
Units: sectors of 1 * 4096 = 4096 bytes ------------------------------> 4k 
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: F1DCBC9E-C1C1-40C9-AA96-A074EEE22514

Device      Start       End   Sectors   Size Type
/dev/sda1     256    153855    153600   600M EFI System
/dev/sda2  153856    415999    262144     1G Linux filesystem
/dev/sda3  416000 146374399 145958400 556.8G Linux LVM