With active mode, the guest write speed is limited by the synchronous
writes to the mirror target. For this reason, management applications
might want to start out in background mode and only switch to active
mode later, when certain conditions are met. This series adds a
block-job-change QMP command to acheive that, as well as
job-type-specific information when querying block jobs, which
can be used to decide when the switch should happen.

For now, only the direction background -> active is supported.

The information added upon querying is whether the target is actively
synced, the total data sent, and the remaining dirty bytes.

Initially, I tried to go for a more general 'job-change' command, but
I couldn't figure out a way to avoid mutual inclusion between
block-core.json and job.json.

Fiona Ebner (9):
  blockjob: introduce block-job-change QMP command
  block/mirror: set actively_synced even after the job is ready
  mirror: implement mirror_change method
  qapi/block-core: use JobType for BlockJobInfo's type
  qapi/block-core: turn BlockJobInfo into a union
  blockjob: query driver-specific info via a new 'query' driver method
  mirror: return mirror-specific information upon query
  mirror: return the remaining dirty bytes upon query
  mirror: return the total number of bytes sent upon query

 block/mirror.c                 | 61 ++++++++++++++++++++++++++++++--
 block/monitor/block-hmp-cmds.c |  4 +--
 blockdev.c                     | 14 ++++++++
 blockjob.c                     | 26 +++++++++++++-
 include/block/blockjob.h       | 11 ++++++
 include/block/blockjob_int.h   | 10 ++++++
 job.c                          |  1 +
 qapi/block-core.json           | 63 ++++++++++++++++++++++++++++++++--
 qapi/job.json                  |  4 ++-
 9 files changed, 184 insertions(+), 10 deletions(-)

-- 
2.30.2

On 24.02.23 17:48, Fiona Ebner wrote:
> With active mode, the guest write speed is limited by the synchronous
> writes to the mirror target. For this reason, management applications
> might want to start out in background mode and only switch to active
> mode later, when certain conditions are met. This series adds a
> block-job-change QMP command to acheive that, as well as
> job-type-specific information when querying block jobs, which
> can be used to decide when the switch should happen.
> 
> For now, only the direction background -> active is supported.
> 
> The information added upon querying is whether the target is actively
> synced, the total data sent, and the remaining dirty bytes.
> 
> Initially, I tried to go for a more general 'job-change' command, but
> I couldn't figure out a way to avoid mutual inclusion between
> block-core.json and job.json.

Hmm, what do you mean? As I understand job-* API is "new" and block-job-* is "old", so we'd better add job-change command

-- 
Best regards,
Vladimir

Am 01.03.23 um 15:34 schrieb Vladimir Sementsov-Ogievskiy:
> On 24.02.23 17:48, Fiona Ebner wrote:
>> With active mode, the guest write speed is limited by the synchronous
>> writes to the mirror target. For this reason, management applications
>> might want to start out in background mode and only switch to active
>> mode later, when certain conditions are met. This series adds a
>> block-job-change QMP command to acheive that, as well as
>> job-type-specific information when querying block jobs, which
>> can be used to decide when the switch should happen.
>>
>> For now, only the direction background -> active is supported.
>>
>> The information added upon querying is whether the target is actively
>> synced, the total data sent, and the remaining dirty bytes.
>>
>> Initially, I tried to go for a more general 'job-change' command, but
>> I couldn't figure out a way to avoid mutual inclusion between
>> block-core.json and job.json.
> 
> Hmm, what do you mean? As I understand job-* API is "new" and
> block-job-* is "old", so we'd better add job-change command
> 

My issue is that when I go for that with a JobChangeOptions union in
job.json and declare JobChangeOptionsMirror in block-core.json (it needs
to know about MirrorCopyMode and all other mirror-related declarations
are there so it's the natural place), then I need to include
block-core.json in job.json so that the JobChangeOptions union can
reference JobChangeOptionsMirror. But that is a mutual inclusion.

I guess it would be possible to move MirrorCopyMode to job.json and
declare JobChangeOptionsMirror in job.json, but that didn't feel right
and would mean moving more and more to job.json whenever extending
job-change requires it.

But maybe I'm missing something obvious? Haven't worked much with the
QAPI yet.