On 8/20/19 7:09 AM, Max Reitz wrote: > On 19.08.19 21:43, Eric Blake wrote: >> On 8/19/19 1:55 PM, Max Reitz wrote: >>> We currently refuse to open qcow2 images with overly long snapshot >>> tables. This patch makes qemu-img check -r all drop all offending >>> entries past what we deem acceptable. >>> >>> Signed-off-by: Max Reitz <mre...@redhat.com> >>> --- >>> block/qcow2-snapshot.c | 88 +++++++++++++++++++++++++++++++++++++----- >>> 1 file changed, 78 insertions(+), 10 deletions(-) >> >> I know I was reluctant in v1, but you also managed to convince me that >> it really takes a LOT of effort to get a table with that many entries. >> And a user has to opt-in to 'qemu-img -r' (it may discard a snapshot >> they value, but that beats not being able to use the image under qemu at >> all, and we don't erase it for plain 'qemu-img check'). So I'm okay >> with this going in. Maybe the commit message can state this sort of >> reasoning. > > So maybe: > > The user cannot choose which snapshots are removed. This is fine > because we have chosen the maximum snapshot table size to be so large > (64 MB) that it cannot be reasonably reached. If the snapshot table > exceeds this size, the image has probably been corrupted in some way; in > this case, it is most important to just make the image usable such that > the user can copy off at least the active layer. > (Also note that the snapshots will be removed only with "-r all", so a > plain "check" or "check -r leaks" will not delete any data.)
I like it. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
