qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Cody <jcody@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: kwolf@redhat.com, benoit.canet@irqsave.net, pkrempa@redhat.com,
	famz@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH v4 05/10] block: Accept node-name arguments for block-commit
Date: Wed, 4 Jun 2014 20:57:54 -0400	[thread overview]
Message-ID: <20140605005754.GC2639@localhost.localdomain> (raw)
In-Reply-To: <538F91EF.2010700@redhat.com>

On Wed, Jun 04, 2014 at 03:38:55PM -0600, Eric Blake wrote:
> On 06/04/2014 07:51 AM, Jeff Cody wrote:
> > This modifies the block operation block-commit so that it will
> > accept node-name arguments for either 'top' or 'base' BDS.
> > 
> > The filename and node-name are mutually exclusive to each other;
> > i.e.:
> >     "top" and "top-node-name" are mutually exclusive (enforced)
> >     "base" and "base-node-name" are mutually exclusive (enforced)
> > 
> > The "device" argument now becomes optional as well, because with
> > a node-name we can identify the block device chain.  It is only
> > optional if a node-name is not specified.
> 
> Stale paragraph; just delete it.  [We may later want to add patches to
> make device optional, if we can figure out a solution for what to do
> when a BDS has more than one overlay; but that doesn't need to stall
> this series]

Argh, yes.  Forgot to update the commit message here, thanks.  If a v5
is needed, I'll delete it, otherwise perhaps a kind maintainer could
fix it up for me before applying :)

> 
> > 
> > The preferred and recommended method now of using block-commit
> > is to specify the BDS to operate on via their node-name arguments.
> > 
> > This also adds an explicit check that base_bs is in the chain of
> > top_bs, because if they are referenced by their unique node-name
> > arguments, the discovery process does not intrinsically verify
> > they are in the same chain.
> > 
> > Signed-off-by: Jeff Cody <jcody@redhat.com>
> > ---
> >  blockdev.c       | 55 +++++++++++++++++++++++++++++++++++++++++++++++--------
> >  qapi-schema.json | 37 +++++++++++++++++++++++++++----------
> >  qmp-commands.hx  | 31 +++++++++++++++++++++++--------
> >  3 files changed, 97 insertions(+), 26 deletions(-)
> > 
> 
> > -    bs = bdrv_find(device);
> > -    if (!bs) {
> > -        error_set(errp, QERR_DEVICE_NOT_FOUND, device);
> > +    /* argument combination validation */
> > +    if (has_base && has_base_node_name) {
> > +        error_setg(errp, "'base' and 'base-node-name' are mutually exclusive");
> > +        return;
> > +    }
> 
> An alternative would have been to validate that both 'base' and
> 'base-node-name' resolve to the same BDS, but I like the simplicity of
> erroring out here.
> 
> > +
> > +    if (bdrv_op_is_blocked(bs, BLOCK_OP_TYPE_COMMIT, errp)) {
> > +        return;
> > +    }
> 
> [unrelated to this commit - are we sure that the semantics of the commit
> blocker are correct? If we implement BDS reuse among multiple chains,
> consider what happens if I have:
>        / sn1 <- sn2
> base <
>        \ file3
> 
> Even if there is no other block job operating on sn2 or its chain, we
> really want to block an attempt to merge file3 into base, as modifying
> base would corrupt both sn1 and sn2.  That is, a BDS being a common
> backing between more than one chain should automatically behave as an
> op-blocker for commits - where the block is what you are committing
> into, not where you are committing from.]


No, the commit blocker likely won't catch everything.  But that is
because there are additional enhancements the blocker code needs (it
is ultimately intended to block on an individual BDS, but in reality
currently operates on the active layer BDS for the whole chain).

For every block job, the appropriate blockers need to be set on each
BDS affected by the job (intermediate images, overlay images in some
cases, the target, etc..).

It currently functions like the older in_use flag (blocks a chain as
referenced by the active layer), but the groundwork is in place for
truly independent BDS blockers to come later.

(For more discussion, see the qemu-devel list replies to:
[PATCH v20 04/15] block: Move op_blocker check from block_job_create to its caller)

> 
> Reviewed-by: Eric Blake <eblake@redhat.com>
>

Thanks!

  reply	other threads:[~2014-06-05  0:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-04 13:51 [Qemu-devel] [PATCH v4 00/10] Modify block jobs to use node-names Jeff Cody
2014-06-04 13:51 ` [Qemu-devel] [PATCH v4 01/10] block: Auto-generate node_names for each BDS entry Jeff Cody
2014-06-04 13:51 ` [Qemu-devel] [PATCH v4 02/10] block: add helper function to determine if a BDS is in a chain Jeff Cody
2014-06-04 13:51 ` [Qemu-devel] [PATCH v4 03/10] block: simplify bdrv_find_base() and bdrv_find_overlay() Jeff Cody
2014-06-04 19:45   ` Eric Blake
2014-06-04 13:51 ` [Qemu-devel] [PATCH v4 04/10] block: make 'top' argument to block-commit optional Jeff Cody
2014-06-04 20:59   ` Eric Blake
2014-06-05  0:26     ` Jeff Cody
2014-06-04 13:51 ` [Qemu-devel] [PATCH v4 05/10] block: Accept node-name arguments for block-commit Jeff Cody
2014-06-04 21:38   ` Eric Blake
2014-06-05  0:57     ` Jeff Cody [this message]
2014-06-04 13:51 ` [Qemu-devel] [PATCH v4 06/10] block: extend block-commit to accept a string for the backing file Jeff Cody
2014-06-04 13:51 ` [Qemu-devel] [PATCH v4 07/10] block: add ability for block-stream to use node-name Jeff Cody
2014-06-05  2:22   ` Eric Blake
2014-06-04 13:51 ` [Qemu-devel] [PATCH v4 08/10] block: add backing-file option to block-stream Jeff Cody
2014-06-04 13:51 ` [Qemu-devel] [PATCH v4 09/10] block: Add QMP documentation for block-stream Jeff Cody
2014-06-04 13:51 ` [Qemu-devel] [PATCH v4 10/10] block: add QAPI command to allow live backing file change Jeff Cody
2014-06-05  2:38   ` Eric Blake
2014-06-05 11:53   ` Benoît Canet

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=20140605005754.GC2639@localhost.localdomain \
    --to=jcody@redhat.com \
    --cc=benoit.canet@irqsave.net \
    --cc=eblake@redhat.com \
    --cc=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pkrempa@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).