Re: [PATCH v3 0/3] Dump QCOW2 metadata

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1639 bytes --]

On 20.02.20 13:10, Vladimir Sementsov-Ogievskiy wrote:
> 20.02.2020 14:58, Max Reitz wrote:
>> On 14.01.20 09:22, Andrey Shinkevich wrote:
>>> The information about QCOW2 metadata allocations in an image ELF-file is
>>> helpful for finding issues with the image data integrity.
>>
>> Sorry that I’m replying only so late – but I don’t know why we need this
>> in qemu, and this cover letter doesn’t provide a justification.  I mean,
>> it isn’t too complex (from the diffstat), but wouldn’t it be better to
>> just have a script for this?
>>
>> I suppose one reason to put it in qemu/qemu-img is that a script
>> wouldn’t be packaged by distributions.  So if a user has a corrupted
>> image, with this series we could tell them to run qemu-img check -M and
>> put the output somewhere.  With a script, we’d first have to tell them
>> to download the script.  But then again, downloading a script (that
>> should be part of the qemu repository) doesn’t seem too much trouble to
>> me either.
>>
>> So I’m curious as to whether you had a specific reason in mind when you
>> decided to implement this as part of qemu itself?
>>
>> (I suppose the additional complexity is fully limited to the check
>> infrastructure, so it wouldn’t interfere with the rest of the qcow2
>> driver.  Hm.  Fair enough.)
>>
> 
> Just not to parse qcow2 from scratch. Qemu already can read qcow2, and
> it looks through all its structures during check, why not
> to add an ability to represent these structures as a qobject?

Because it’d be code in qemu (i.e., a liability) that users are pretty
much never going to use.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]