Fiona Ebner <f.eb...@proxmox.com> writes:
> Changes in v3:
> * unlock the job mutex when calling the new block job driver
> 'query' handler
> * squash patch adapting iotest output into patch that changes the
> output
> * turn accesses to copy_mode and actively_synced atomic
> * slightly rework error handling in mirror_change
>
> Changes in v2:
> * move bitmap to filter which allows to avoid draining when
> changing the copy mode
> * add patch to determine copy_to_target only once
> * drop patches returning redundant information upon query
> * update QEMU version in QAPI
> * update indentation in QAPI
> * update indentation in QAPI (like in a937b6aa73 ("qapi: Reformat
> doc comments to conform to current conventions"))
> * add patch to adapt iotest output
>
> Discussion of v2:
> https://lists.nongnu.org/archive/html/qemu-devel/2023-10/msg02290.html
>
> Discussion of v1:
> https://lists.nongnu.org/archive/html/qemu-devel/2023-02/msg07216.html
>
> 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 achieve 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
> to avoid mutual inclusion of block-core.json and job.json, more
> preparation would be required.
Can you elaborate a bit? A more generic command is preferable, and we
need to understand what it would take.
