[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 07/12] block/backup: add 'always' bitmap sync po
From: |
Max Reitz |
Subject: |
Re: [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
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-devel] [PATCH 02/12] block/backup: Add mirror sync mode 'bitmap', (continued)
- [Qemu-devel] [PATCH 07/12] block/backup: add 'always' bitmap sync policy, John Snow, 2019/06/19
- Re: [Qemu-devel] [PATCH 07/12] block/backup: add 'always' bitmap sync policy, Vladimir Sementsov-Ogievskiy, 2019/06/21
- Re: [Qemu-devel] [PATCH 07/12] block/backup: add 'always' bitmap sync policy, Vladimir Sementsov-Ogievskiy, 2019/06/21
- Re: [Qemu-devel] [PATCH 07/12] block/backup: add 'always' bitmap sync policy, Vladimir Sementsov-Ogievskiy, 2019/06/21
- Re: [Qemu-devel] [PATCH 07/12] block/backup: add 'always' bitmap sync policy, Vladimir Sementsov-Ogievskiy, 2019/06/21
- Re: [Qemu-devel] [PATCH 07/12] block/backup: add 'always' bitmap sync policy, John Snow, 2019/06/21
- Re: [Qemu-devel] [PATCH 07/12] block/backup: add 'always' bitmap sync policy,
Max Reitz <=
- Re: [Qemu-devel] [PATCH 07/12] block/backup: add 'always' bitmap sync policy, John Snow, 2019/06/21
[Qemu-devel] [PATCH 06/12] block/dirty-bitmap: add bdrv_dirty_bitmap_claim, John Snow, 2019/06/19
[Qemu-devel] [PATCH 04/12] hbitmap: Fix merge when b is empty, and result is not an alias of a, John Snow, 2019/06/19
[Qemu-devel] [PATCH 05/12] hbitmap: enable merging across granularities, John Snow, 2019/06/19