Hi, What exactly do you mean by “file size”? The file length (as reported by ls -l) or the bytes used on disk (reported as “disk size” by qemu- img, or by du -B1)?
You say that qcow2 and vmdk are normal – do you mean as input or as output formats? One thing that comes to my mind is that from http, we have no way of inquiring about holes in the source file, so we have to scan the file for ranges that are zero, which may not be optimal. OTOH, the default minimum-zero length is 4 kB, which should basically be the granularity at which filesystems can record and report holes, too. (And if that’s the problem, it should present itself regardless of the output format.) Can you paste the output for “qemu-img map” on your source file somewhere (the local one), or is that too long? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1888467 Title: qemu-img http convert bug Status in QEMU: New Bug description: Hello, Why the file sizes of http conversion and local conversion are inconsistent? Use the http method of qemu-img for conversion. The size of some formats after conversion is different from the local method of qemu-img. Such as vhd, vdi. qcow2 and vmdk are normal。 My image size is 40 G, raw format. The source is the same file, but the access method is different http method of qemu-img： qemu-img convert -f raw -O vdi http://xxx xxx.vdi（19G，after conversion） local method of qemu-img： qemu-img convert -f raw -O vdi xxx.raw xxx.vdi（3G，after conversion） thank you To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1888467/+subscriptions
