From: Kevin Wolf <kwolf@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: qemu-block@nongnu.org, pkrempa@redhat.com, jtc@redhat.com,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC v4 15/21] blockjobs: add prepare callback
Date: Wed, 28 Feb 2018 18:04:54 +0100 [thread overview]
Message-ID: <20180228170454.GI4855@localhost.localdomain> (raw)
In-Reply-To: <20180223235142.21501-16-jsnow@redhat.com>
Am 24.02.2018 um 00:51 hat John Snow geschrieben:
> Some jobs upon finalization may need to perform some work that can
> still fail. If these jobs are part of a transaction, it's important
> that these callbacks fail the entire transaction.
>
> We allow for a new callback in addition to commit/abort/clean that
> allows us the opportunity to have fairly late-breaking failures
> in the transactional process.
>
> The expected flow is:
>
> - All jobs in a transaction converge to the WAITING state
> (added in a forthcoming commit)
> - All jobs prepare to call either commit/abort
> - If any job fails, is canceled, or fails preparation, all jobs
> call their .abort callback.
> - All jobs enter the PENDING state, awaiting manual intervention
> (also added in a forthcoming commit)
> - block-job-finalize is issued by the user/management layer
> - All jobs call their commit callbacks.
>
> Signed-off-by: John Snow <jsnow@redhat.com>
You almost made me believe the scary thought that we need transactional
graph modifications, but after writing half of the reply, I think it's
just that your order here is wrong.
So .prepare is the last thing in the whole process that is allowed to
fail. Graph manipulations such as bdrv_replace_node() can fail. Graph
manipulations can also only be made in response to block-job-finalize
because the management layer must be aware of them. Take them together
and you have a problem.
Didn't we already establish earlier that .prepare/.commit/.abort must be
called together and cannot be separated by waiting for a QMP command
because of locking and things?
So if you go to PENDING first, then wait for block-job-finalize and only
then call .prepare/.commit/.abort, we should be okay for both problems.
And taking a look at the final state, that seems to be what you do, so
in the end, it's probably just the commit message that needs a fix.
> blockjob.c | 34 +++++++++++++++++++++++++++++++---
> include/block/blockjob_int.h | 10 ++++++++++
> 2 files changed, 41 insertions(+), 3 deletions(-)
>
> diff --git a/blockjob.c b/blockjob.c
> index 8f02c03880..1c010ec100 100644
> --- a/blockjob.c
> +++ b/blockjob.c
> @@ -394,6 +394,18 @@ static void block_job_update_rc(BlockJob *job)
> }
> }
>
> +static int block_job_prepare(BlockJob *job)
> +{
> + if (job->ret) {
> + goto out;
> + }
> + if (job->driver->prepare) {
> + job->ret = job->driver->prepare(job);
> + }
> + out:
> + return job->ret;
> +}
Why not just if (job->ret == 0 && job->driver->prepare) and save the
goto?
Kevin
next prev parent reply other threads:[~2018-02-28 17:05 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-23 23:51 [Qemu-devel] [RFC v4 00/21] blockjobs: add explicit job management John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 01/21] blockjobs: fix set-speed kick John Snow
2018-02-27 16:32 ` Eric Blake
2018-02-27 17:18 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 02/21] blockjobs: model single jobs as transactions John Snow
2018-02-27 16:36 ` Eric Blake
2018-02-27 17:18 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 03/21] blockjobs: add manual property John Snow
2018-02-27 16:39 ` Eric Blake
2018-02-27 17:18 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 04/21] blockjobs: add status enum John Snow
2018-02-27 16:44 ` Eric Blake
2018-02-27 17:19 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 05/21] blockjobs: add state transition table John Snow
2018-02-27 16:27 ` Kevin Wolf
2018-02-27 16:45 ` John Snow
2018-02-27 17:08 ` Kevin Wolf
2018-02-27 18:58 ` John Snow
2018-02-27 18:58 ` Eric Blake
2018-02-27 19:06 ` John Snow
2018-02-27 19:22 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 06/21] iotests: add pause_wait John Snow
2018-02-27 17:19 ` Kevin Wolf
2018-02-27 19:01 ` Eric Blake
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 07/21] blockjobs: add block_job_verb permission table John Snow
2018-02-27 17:19 ` Kevin Wolf
2018-02-27 19:25 ` Eric Blake
2018-02-27 19:38 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 08/21] blockjobs: add ABORTING state John Snow
2018-02-27 19:34 ` Eric Blake
2018-02-28 14:54 ` Kevin Wolf
2018-02-28 19:26 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 09/21] blockjobs: add CONCLUDED state John Snow
2018-02-27 19:38 ` Eric Blake
2018-02-27 19:44 ` John Snow
2018-02-28 15:37 ` Kevin Wolf
2018-02-28 19:29 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 10/21] blockjobs: add NULL state John Snow
2018-02-27 19:41 ` Eric Blake
2018-02-28 15:42 ` Kevin Wolf
2018-02-28 20:04 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 11/21] blockjobs: add block_job_dismiss John Snow
2018-02-27 19:44 ` Eric Blake
2018-02-28 15:53 ` Kevin Wolf
2018-02-28 20:35 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 12/21] blockjobs: ensure abort is called for cancelled jobs John Snow
2018-02-27 19:49 ` Eric Blake
2018-02-27 20:43 ` John Snow
2018-02-28 16:05 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 13/21] blockjobs: add commit, abort, clean helpers John Snow
2018-02-27 19:50 ` Eric Blake
2018-02-28 16:07 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 14/21] blockjobs: add block_job_txn_apply function John Snow
2018-02-27 19:52 ` Eric Blake
2018-02-28 16:32 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 15/21] blockjobs: add prepare callback John Snow
2018-02-27 19:56 ` Eric Blake
2018-02-27 20:45 ` John Snow
2018-02-28 17:04 ` Kevin Wolf [this message]
2018-03-07 3:19 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 16/21] blockjobs: add waiting status John Snow
2018-02-27 20:00 ` Eric Blake
2018-02-27 20:50 ` John Snow
2018-02-28 17:46 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 17/21] blockjobs: add PENDING status and event John Snow
2018-02-27 20:05 ` Eric Blake
2018-02-27 20:54 ` John Snow
2018-02-28 17:55 ` Kevin Wolf
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 18/21] blockjobs: add block-job-finalize John Snow
2018-02-27 20:13 ` Eric Blake
2018-02-28 18:15 ` Kevin Wolf
2018-02-28 19:14 ` John Snow
2018-03-01 10:01 ` Kevin Wolf
2018-03-01 19:24 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 19/21] blockjobs: Expose manual property John Snow
2018-02-27 20:16 ` Eric Blake
2018-02-27 20:42 ` John Snow
2018-02-27 21:57 ` John Snow
2018-02-27 22:27 ` Eric Blake
2018-02-28 18:23 ` Kevin Wolf
2018-02-28 19:19 ` John Snow
2018-02-28 18:25 ` Kevin Wolf
2018-02-28 19:20 ` John Snow
2018-02-28 19:27 ` [Qemu-devel] [Qemu-block] " Eric Blake
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 20/21] iotests: test manual job dismissal John Snow
2018-02-27 20:21 ` Eric Blake
2018-02-27 20:41 ` John Snow
2018-02-23 23:51 ` [Qemu-devel] [RFC v4 21/21] blockjobs: add manual_mgmt option to transactions John Snow
2018-02-27 20:24 ` Eric Blake
2018-02-28 18:29 ` Kevin Wolf
2018-02-28 19:24 ` John Snow
2018-03-01 10:10 ` Kevin Wolf
2018-02-24 0:30 ` [Qemu-devel] [RFC v4 00/21] blockjobs: add explicit job management no-reply
2018-02-24 14:31 ` no-reply
2018-02-27 21:01 ` John Snow
2018-02-28 18:32 ` Kevin Wolf
2018-02-25 23:25 ` no-reply
2018-02-27 20:58 ` John Snow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180228170454.GI4855@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=jsnow@redhat.com \
--cc=jtc@redhat.com \
--cc=pkrempa@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.