Re: [PATCH] block/mirror: add 'write-blocking-after-ready' copy mode

[Vladimir Sementsov-Ogievskiy]

On 02.02.23 18:23, Kevin Wolf wrote:
> Am 02.02.2023 um 14:35 hat Denis V. Lunev geschrieben:
> > On 2/2/23 14:27, Fiona Ebner wrote:
> > > Am 02.02.23 um 12:34 schrieb Kevin Wolf:
> > > > Am 02.02.2023 um 11:19 hat Fiona Ebner geschrieben:
> > > > > Am 31.01.23 um 19:18 schrieb Denis V. Lunev:
> > > > > > Frankly speaking I would say that this switch could be considered
> > > > > > NOT QEMU job and we should just send a notification (event) for the
> > > > > > completion of the each iteration and management software should
> > > > > > take a decision to switch from async mode to the sync one.
> > > > My first thought was very similar. We should provide a building block
> > > > that just switches between the two modes and then the management tool
> > > > can decide what the right policy is.
> > > >
> > > > Adding a new event when the first iteration is done (I'm not sure if
> > > > there is much value in having it for later iterations) makes sense to
> > > > me if someone wants to use it. If we add it, let's not forget that
> > > > events can be lost and clients must be able to query the same
> > > > information, so we'd have to add it to query-jobs, too - which in turn
> > > > requires adding a job type specific struct to JobInfo first.
> > > Well, Denis said 2 iterations might be better. But I'm fine with
> > > initially adding an event just for the first iteration, further ones can
> > > still be added later. Returning the number of completed iterations as
> > > part of the mirror-specific job info would anticipate that.
> >
> > May be it would be better to have an event on each iteration + make
> > available iteration count over block status query.
>
> In the ready phase, each iteration can be very short. Basically if the
> guest writes to one block and then the mirror catches up, that's a whole
> iteration. So if the guest is doing I/O at a moderate rate so that the
> host can keep up with it, you might end up with one QMP event per I/O
> request.

I think, after first iteration the only physical parameters are data_sent and 
remaining_dirty. Number of additional iterations doesn't matter - we just loop 
through dirty bits.

I'm not even sure that first iteration completion has physical meaning.. Probably, 
"the whole disk touched", so we can make more reasonable prediction about 
further speed and convergence..

--
Best regards,
Vladimir