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
signature.asc
Description: OpenPGP digital signature
