qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] block/snapshot: dirty all dirty bitmaps on snap


From: John Snow
Subject: Re: [Qemu-devel] [PATCH] block/snapshot: dirty all dirty bitmaps on snapshot-switch
Date: Fri, 17 Nov 2017 15:40:16 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0


On 11/17/2017 01:25 PM, Kevin Wolf wrote:
> Am 17.11.2017 um 19:15 hat John Snow geschrieben:
>>
>>
>> On 11/17/2017 10:01 AM, Max Reitz wrote:
>>> On 2017-11-17 13:30, Kevin Wolf wrote:
>>>> Am 23.10.2017 um 11:29 hat Vladimir Sementsov-Ogievskiy geschrieben:
>>>>> Snapshot-switch actually changes active state of disk so it should
>>>>> reflect on dirty bitmaps. Otherwise next incremental backup using
>>>>> these bitmaps will be invalid.
>>>>>
>>>>> Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
>>>>
>>>> We discussed this quite a while ago, and I'm still not convinced that
>>>> this approach makes sense.
>>>
>>> I think it at least makes more sense than not handling this case at all.
>>>
>>>> Can you give just one example of a use case where dirtying the whole
>>>> bitmap while loading a snapshot is the desired behaviour?
>>>>
>>>> I think the most useful behaviour would be something where the bitmaps
>>>> themselves are snapshotted, too.
>>>
>>> Agreed.
>>>
>>>>                                  But for the time being, the easiest and
>>>> safest solution might just be to error out in any snapshot operations
>>>> if any bitmaps are in use.
>>>
>>> Sounds OK, too.  I personally don't have an opinion either way.
>>>
>>> But in any case, what we did before this patch was definitely wrong so I
>>> consider it an improvement.
>>>
>>
>> This is how I feel about it too. Erroring out entirely is an option, but
>> code-wise just dirtying everything is at least verifiably not-wrong and
>> pretty simple to implement.
> 
> But that's exactly the problem: If something is just plain wrong, you
> can always replace it with something that makes sense. If it errors out,
> you can still remove that error later. But if you have something that
> doesn't make a whole lot of sense, but kinda sorta works (like after
> this patch), it's ABI and you can't implement something more useful
> later any more.
> 
>> It's an improvement... Don't do it, but at least you won't get
>> something wrong after, just something heinously unoptimal.
> 
> It's a short-term improvement that may become a long-term burden.
> 
> Kevin
> 

I see your point.

If we enable it now, we always have to.
If we disable it now, we *can* later if we wish.

...however, I think it's been the case that we haven't prohibited it
before, but also it's a pretty good case that nobody has been using this
feature in production because they're not yet persistent and migratable.

An error message asking the user to delete bitmaps (which will very
obviously invalidate them) would be fine, too. I was erring on the side
of "just let things work," but you have a point that making sure the
user knows that what they're trying to accomplish is not a good idea is
probably better than silently doing the very stupid thing.



reply via email to

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