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 >> --- >> 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.) ? Max