qemu-block
[Top][All Lists]
Advanced

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

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


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-block] [PATCH] block/snapshot: dirty all dirty bitmaps on snapshot-switch
Date: Mon, 20 Nov 2017 15:00:52 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

20.11.2017 12:51, Vladimir Sementsov-Ogievskiy wrote:
17.11.2017 23:40, John Snow wrote:

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.

Hi all. erroring  is ok for me too. And looks like it's a way which looks ok for all interested in. Should I make a patch?


Hmm, it looks not so easy: errp infrastructure is absent here, and returning just EINVAL is not very informative.

--
Best regards,
Vladimir




reply via email to

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