qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [PATCH v3 05/15] block/mirror: don't install backing ch


From: Kevin Wolf
Subject: Re: [Qemu-block] [PATCH v3 05/15] block/mirror: don't install backing chain on abort
Date: Wed, 5 Sep 2018 11:54:31 +0200
User-agent: Mutt/1.9.1 (2017-09-22)

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.

Kevin



reply via email to

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