qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 00/10] mirror: allow switching from background to active m


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [PATCH v2 00/10] mirror: allow switching from background to active mode
Date: Tue, 10 Oct 2023 23:01:01 +0300
User-agent: Mozilla Thunderbird

On 10.10.23 20:55, Vladimir Sementsov-Ogievskiy wrote:
On 09.10.23 12:46, Fiona Ebner wrote:
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 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
I couldn't figure out a way to avoid mutual inclusion between
block-core.json and job.json.


What is the problem with it? I still think that job-change would be better.

However, that's not a show-stopper. We have block-job-* commands, they are not 
deprecated, no problem to add one more.

--
Best regards,
Vladimir




reply via email to

[Prev in Thread] Current Thread [Next in Thread]