08.06.2020 12:21, Kevin Wolf wrote:
Am 06.06.2020 um 08:55 hat Vladimir Sementsov-Ogievskiy geschrieben:
05.06.2020 13:59, Peter Krempa wrote:
On Fri, Jun 05, 2020 at 12:07:47 +0200, Kevin Wolf wrote:
Am 05.06.2020 um 11:58 hat Peter Krempa geschrieben:
On Fri, Jun 05, 2020 at 11:44:07 +0200, Kevin Wolf wrote:
[...]
The above was actually inspired by a very recent problem I have in my
attempt to use the dirty bitmap populate job to refactor how libvirt
handles bitmaps. I've just figured out that I need to shuffle around
some stuff as I can't run the dirty-bitmap-populate job while an active
layer commit is in synchronised phase and I wanted to do the merging at
that point. That reminded me of a possible gotcha in having to sequence
the blockjobs which certainly would be more painful.
It would probably be good to have not only an iotests case that tests
the low-level functionality of the block job, but also one that
resembles the way libvirt would actually use it in combination with
other jobs.
Hi! Sorry me missing the discussion for a long time.
About new job semantics: if you create temporary bitmaps anyway, I do
think that we should allow to populate into target bitmap directly,
without creating any internal temporary bitmaps. I suggested it when
reviewing v1, John argued for more transaction-like semantics to look
like other jobs. Still, we can support both modes if we want.
But don't all other jobs allow you to see intermediate states? Like,
when you look at the target node in the middle of a mirror job, you'll
see a half-updated target image.
That was my argument on v1 :)
If we have an actual use case for both modes, we can certainly support
that, but do we have one?
No. We have only one: without extra temporary bitmap, let's implement it.
We can always add transaction-like case later on demand.
Allowing to use one target for several populating job is an
interesting idea. Current series does
"bdrv_dirty_bitmap_set_busy(target_bitmap, true);", which forbids it..
Hmm. If we just drop it, nothing prevents user just remove target
bitmap during the job. So, we'll need something like collective-busy
bitmap..
I'm not sure for what the busy flag is used in detail, but if this is
the problem, maybe it's possible to just replace it with a counter?
busy flag means that bitmap is already in-use by some process (for example
backup, or exported through NBD, or being migrated). User can't change or
use busy bitmaps for another jobs. So multiple jobs writing into one bitmaps
should be an exclusion from this rule (we want to allow several similar
block-jobs, but still don't want to allow migration or NBD-export in the same
time, or bitmap removing). I think we can just hardcode this case, add a new
flag, which says that bitmap is used as target of populating jobs and being
busy still allowed as a target for another populating job.
--
Best regards,
Vladimir
