All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Benoît Canet" <benoit.canet@irqsave.net>
To: Eric Blake <eblake@redhat.com>
Cc: "Benoît Canet" <benoit.canet@irqsave.net>,
	kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com,
	mreitz@redhat.com
Subject: Re: [Qemu-devel] [PATCH v7 2/3] block: Add node-name and to-replace-node-name arguments to drive-mirror
Date: Tue, 10 Jun 2014 08:12:12 +0200	[thread overview]
Message-ID: <20140610061212.GA32204@irqsave.net> (raw)
In-Reply-To: <5396224D.9070504@redhat.com>

The Monday 09 Jun 2014 à 15:08:29 (-0600), Eric Blake wrote :
> On 06/09/2014 02:46 PM, Benoît Canet wrote:
> > node-name gives a name to the created BDS and registers it in the node graph.
> > 
> > to-replace-node-name can be used when drive-mirror is called with sync=full.
> 
> Why can't it work with other modes?  That is, if I have:
> 
> base1 <- snap1 \
> base2 <- snap2  > quorum
> base3 <- snap3 /
> 
> and want to replace the 'base3 <- snap3' arm of the quorum with 'base4
> <- snap4', where base3 and base4 are identical, the fact that you are
> forcing sync=full will not let me do so.  There's a lot of things where
> if management does something stupid, then the guest will see data
> instantly corrupted; but that doesn't mean that we necessarily have to
> cripple the power of the command.

I am affraid that the user could form loop in the graph.

> 
> > 
> > The purpose of these fields is to be able to reconstruct and replace a broken
> > quorum file.
> > 
> > drive-mirror will bdrv_swap the new BDS named node-name with the one
> > pointed by to-replace-node-name when the mirroring is finished.
> > 
> > Signed-off-by: Benoit Canet <benoit@irqsave.net>
> > ---
> 
> > +
> > +        if (size < bdrv_getlength(to_replace_bs)) {
> > +            error_setg(errp, "cannot replace to-replace-node-name image with a "
> > +                             "mirror image that would be smaller in size");
> 
> Should this be enforcing equality in size, rather than just prohibiting
> shrinking?  Doesn't the quorum code already require that all quorum
> members have equal size?

I though that quorum was still returning the smallest image size for getlength
and that it would be a way to grow the quorum by replacing with bigger image.
But it's not the case I will enforce equality in size.

> 
> 
> >  
> > +    /* if we are planning to replace a graph node name the code should do a full
> > +     * mirror of the source image
> > +     */
> > +    if (has_to_replace_node_name && sync != MIRROR_SYNC_MODE_FULL) {
> > +        error_setg(errp,
> > +                   "to-replace-node-name can only be used with sync=full");
> > +        return;
> > +    }
> 
> Again, I'm not sure if this restriction makes sense.
> 
> > +++ b/qapi/block-core.json
> > @@ -769,6 +769,14 @@
> >  # @format: #optional the format of the new destination, default is to
> >  #          probe if @mode is 'existing', else the format of the source
> >  #
> > +# @new-node-name: #optional the new block driver state node name in the graph
> > +#                 (Since 2.1)
> 
> Is it worth splitting this patch into two? The ability to name the new
> node of a drive-mirror makes sense as an independent patch, which might
> be applied sooner even while worrying about the semantics of how
> replacement will work.

ok

> 
> > +#
> > +# @to-replace-node-name: #optional with sync=full graph node name to be
> > +#                        replaced by the new image when a whole image copy is
> > +#                        done. This can be used to repair broken Quorum files.
> > +#                        (Since 2.1)
> 
> So if I understand correctly, the point of this command is that if I
> have a quorum with three backing named nodes, and want to hotswap out
> one of those modes, then I create a drive-mirror that names which of the
> three nodes is the victim, and on completion, the quorum now has the
> remaining two nodes and my new mirror as its new three node setup.
> 
> Am I correct that to-replace-node-name can only be used on a node that
> is already composed of other nodes, and that the replacement must be one
> of those nodes?
> 
> What if I have a 3/5 quorum - can I replace 2 nodes at once?

No you can't.
The first drive-mirror will lock the quorum device.

> 
> > +#
> >  # @mode: #optional whether and how QEMU should create a new image, default is
> >  #        'absolute-paths'.
> >  #
> > @@ -801,6 +809,7 @@
> >  ##
> >  { 'command': 'drive-mirror',
> >    'data': { 'device': 'str', 'target': 'str', '*format': 'str',
> > +            '*new-node-name': 'str', '*to-replace-node-name': 'str',
> 
> Bikeshedding: those are some long names.  Is it sufficient to go with
> something shorter, '*node-name' for what to name the new mirror (again,
> might be worth splitting that into its own patch), and '*replaces' for
> the name of a node to be replaced?

ok

> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 

  reply	other threads:[~2014-06-10  6:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-09 20:45 [Qemu-devel] [PATCH v7 0/3] Quorum maintainance operations Benoît Canet
2014-06-09 20:45 ` [Qemu-devel] [PATCH v7 1/3] quorum: Add the rewrite-corrupted parameter to quorum Benoît Canet
2014-06-09 20:46 ` [Qemu-devel] [PATCH v7 2/3] block: Add node-name and to-replace-node-name arguments to drive-mirror Benoît Canet
2014-06-09 21:08   ` Eric Blake
2014-06-10  6:12     ` Benoît Canet [this message]
2014-06-09 20:46 ` [Qemu-devel] [PATCH v7 3/3] qemu-iotests: Add TestRepairQuorum to 041 to test drive-mirror node-name mode 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=20140610061212.GA32204@irqsave.net \
    --to=benoit.canet@irqsave.net \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@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 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.