[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
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH v3 05/15] block/mirror: don't install backing chain on abort |
Date: |
Tue, 4 Sep 2018 14:30:00 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
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).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org