Re: [PATCH RFC v2 1/5] block: add bitmap-populate job

[Kevin Wolf]

Am 08.06.2020 um 12:00 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 08.06.2020 12:21, Kevin Wolf wrote:
> > Am 06.06.2020 um 08:55 hat Vladimir Sementsov-Ogievskiy geschrieben:
> > > 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.

I think this rule is overly restrictive. That you can't delete a bitmap
that is in use is obvious. That you can't have more than one "consumer"
of dirty bits that clears bits after processing them seems at least
reasonable. But why shouldn't you be able to have more than one
"producer" of dirty bits?

> 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.

I think we need to find a more general pattern. Maybe the distinction I
made above between producer (setting dirty bits) and consumer (clearing
dirty bits) is what we need, or maybe we need something else to
distinguish roles. But I don't think the definition should have any
reference to bitmap-populate.

Kevin