Re: [Qemu-block] "qemu-img: File contains external, encrypted or compressed clusters."

[Eric Blake]

On 3/28/19 5:59 AM, Richard W.M. Jones wrote:
> This error message is confusing and looks wrong to me:

Confusing, but intentional design decision at the time (that said, I
would also welcome an improvement).

> 
> $ ./nbdkit -U - data data="1" size=1M --run 'qemu-img map $nbd'
> Offset          Length          Mapped to       File
> qemu-img: File contains external, encrypted or compressed clusters.

It's due to the fact that the human output WANTS to fill in the "mapped
to" column, but can't, because there is no "File" that you can open and
read from the "Mapped to" offset of that file to see the same thing as
the guest would see at "Offset".

Perhaps if we tweaked the output to just say:

$ qemu-img map file
Offset          Length          Mapped to       File
0               0x1000          N/A
(try again with --output=json for full details)
$

for all rows where there is no direct mapping (whether that is because
the mapping is compressed, encrypted, or external), rather than giving
up on the entire human-readable output, that would make things nicer.

> 
> With JSON output it's fine:
> 
> $ ./nbdkit -U - data data="1" size=1M --run 'qemu-img map --output=json $nbd'
> [{ "start": 0, "length": 32768, "depth": 0, "zero": false, "data": true},
> { "start": 32768, "length": 1015808, "depth": 0, "zero": true, "data": false}]

Yes, it is intentional that the JSON output is 100% accurate, while the
human output tries to compress and highlight only the useful information
(that is, it was an intentional decision for the human output to skip
holes and to coalesce consecutive regions with similar enough status)

> 
> Looking at the source code the error seems to be related to the first
> extent having data=true but no "offset" (whatever that is), but I
> don't understand what it's trying to say.
> 
> It doesn't happen with local sparse files:
> 
> $ virt-builder fedora-28
> $ qemu-img map fedora-28.img 
> Offset          Length          Mapped to       File
> 0               0x10000         0               fedora-28.img
> 0x100000        0x10000         0x100000        fedora-28.img
> 0x200000        0xb0000         0x200000        fedora-28.img
> [etc]

Well, that's because local files DO have all regions readable by
open()ing the file and reading at the "Mapped to" location.

We are, however, too late in the 4.0 cycle for me to feel comfortable
calling such a change to the human output as being a bug fix; so this
sounds like 4.1 material.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature