[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 05/15] block/mirror: don't install backing ch
Re: [Qemu-devel] [PATCH v3 05/15] block/mirror: don't install backing chain on abort
Wed, 5 Sep 2018 08:59:07 -0400
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
On 09/05/2018 05:54 AM, Kevin Wolf wrote:
> Am 04.09.2018 um 21:30 hat Eric Blake geschrieben:
>> On 09/04/2018 02:15 PM, John Snow wrote:
>>> post-script: I really, really hate the "fake cancel" we've implemented
>>> for mirror. It makes the job logic so much worse.
>> Mirror really does have a tri-state way to end the job (and accessible only
>> after the job has moved into the sync state):
>> cancel (gracefully end the job by detaching the mirror, so that the original
>> volume remains active - your "fake cancel")
>> complete (gracefully end the job by pivoting to the mirror, so that the
>> original volume is now the backup)
>> cancel --force (end the job now, even though it means you did not actually
>> create a mirrored copy) - only useful since commit b76e4458 (2.12)
>> The first two are conceptually similar - the job succeeds, and one of the
>> two files used in the mirroring is now the state of the other at the time
>> the job concluded.
>> Back-compat says we can't really change the block-job terminology without an
>> adequate deprecation cycle (and I don't know if libvirt has even been taught
>> about cancel --force yet); but for the newer 'job' functionality (which we
>> tried to shoehorn existing block jobs into), it does seem like it would be
>> nicer to have 'cancel' mean what blockjob cancel --force implies, and
>> instead focus on teaching 'complete' to have a way to select which of the
>> two completion modes are desired (complete by return to original, or
>> complete by pivot to mirror). It might even be nice to have a way to
>> specify which completion mode to default to at job creation time, and/or to
>> change that default as the job is running (which also implies being able to
>> query which completion mode is currently tied to the job, if you can
>> complete without requesting either of the two modes explicitly).
> I think it's better to select the completion mode in the job-complete
> command than having to specify it from the start.
> Once we have support multiple completion modes (even just internally),
> nothing stops us from moving the "fake cancel" logic to the QMP layer
> (i.e. the drive-mirror/blockdev-mirror implementations) and get rid of
> it in the actual job.
Oh! I hadn't considered that specific tactic before. That's a very good