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

[John Snow]

On 09/04/2018 03:30 PM, Eric Blake wrote:
> 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.
> 

Sure, but I dislike how we implemented it as cancel, which mucks up the
job mechanisms. I recognize there are two fully valid ways in which we
want to successfully complete a mirror job.

> 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).
> 

Yup, that's my preference!