[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Max Reitz
Subject: Re: [Qemu-block] [PATCH v2 12/16] qcow2: Fix overly long snapshot tables
Date: Tue, 20 Aug 2019 14:09:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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



Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]