qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [PATCH 07/12] block/backup: add 'always' b


From: Max Reitz
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 07/12] block/backup: add 'always' bitmap sync policy
Date: Fri, 21 Jun 2019 23:48:37 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

On 21.06.19 22:58, John Snow wrote:
> 
> 
> On 6/21/19 9:44 AM, Vladimir Sementsov-Ogievskiy wrote:

[...]

Just chiming in on this:

>> "So on cancel and abort you synchronize bitmap too?"
> 
> I will concede that this means that if you ask for a bitmap backup with
> the 'always' policy and, for whatever reason change your mind about
> this, there's no way to "cancel" the job in a manner that does not edit
> the bitmap at this point.
> 
> I do agree that this seems to go against the wishes of the user, because
> we have different "kinds" of cancellations:
> 
> A) Cancellations that actually represent failures in transactions
> B) Cancellations that represent genuine user intention
> 
> It might be nice to allow the user to say "No wait, please don't edit
> that bitmap, I made a mistake!"

So that “always” doesn’t mean “always”?  To me, that seems like not so
good an idea.

If the user uses always, they have to live with that.  I had to live
with calling “rm” on the wrong file before.  Life’s tough.

In all seriousness: “Always” is not something a user would use, is it?
It’s something for management tools.  Why would they cancel because
“They made a mistake”?

Second, what’s the worst thing that may come out of such a mistake?
Having to perform a full backup?  If so, that doesn’t seem so bad to me.
 It certainly doesn’t seem so bad to make an unrelated mechanic have an
influence on whether “always” means “always”.

Also, this cancel idea would only work for jobs where the bitmap mode
does not come into play until the job is done, i.e. backup.  I suppose
if we want to have bitmap modes other than 'always' for mirror, that too
would have to make a copy of the user-supplied bitmap, so there the
bitmap mode would make a difference only at the end of the job, too, but
who knows.

And if it only makes a difference at the end of the job, you might as
well just add a way to change a running job’s bitmap-mode.

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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