Re: [Qemu-devel] [PATCH v2 12/16] qcow2: Fix overly long snapshot tables

[Eric Blake]

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 <address@hidden>
>>> ---
>>>  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