qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: "Benoît Canet" <benoit.canet@irqsave.net>, qemu-devel@nongnu.org
Cc: kwolf@redhat.com, jcody@redhat.com,
	Benoit Canet <benoit@irqsave.net>,
	stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH] block: Make op blocker recursive
Date: Thu, 19 Jun 2014 14:13:20 -0600	[thread overview]
Message-ID: <53A34460.8010302@redhat.com> (raw)
In-Reply-To: <1403208081-18247-2-git-send-email-benoit.canet@irqsave.net>

[-- Attachment #1: Type: text/plain, Size: 4242 bytes --]

On 06/19/2014 02:01 PM, Benoît Canet wrote:
> As the code will start to operate on arbitratry nodes we need the op blocker

s/arbitratry/arbitrary/

> to recursively block or unblock whole BDS subtrees.
> 
> Also add a function to reset all blocker from a BDS.
> 
> This patch also take care of changing blocker user so they are not broken.
> 
> Signed-off-by: Benoit Canet <benoit@irqsave.net>
> ---

> +
> +/* This remove unconditionally all blockers of type op of the subtree */

This unconditionally removes all blockers of type op of the subtree

Yikes - is that really what we want?  Or do we need to start doing
blocker reference counting?

Consider:

base <- snap1 <- active

Looking at Jeff's proposal of making blockers based on access patterns
rather than operations, we want the mere act of being a backing file to
automatically put a guest_write block on base and snap1 (we must not
modify the backing chain out of underneath active).  But now suppose we
do two operations in parallel - we take a fleecing export of active, and
we start a drive-mirror on active.

base <- snap1 <- active
              |        \-- fleecing
              \-- copy

Both of those actions should be doable in parallel, and both of them
probably put additional blocker restrictions on the chain.  But if we
unconditionally clear those additional restrictions on the first of the
two jobs ending, that would inappropriately stop blocking that action
from the still on-going second action.  The only way I see around that
is via reference-counted blocking.  Definitely not 2.1 material (but
good to be thinking about it now, so we can get it in early in the 2.2
cycle).


>  
> +/* This remove unconditionally all blockers */

Unconditionally remove all blockers


>  
> +/* Used to prevent recursion loop. A case exists in block commit mirror usage */
> +static BlockDriverState *recurse_op_bs = NULL;
> +/* take note of the recursion depth to allow assigning recurse_op_bs once */
> +static uint64_t recurse_op_depth = 0;

The '= 0' is redundant; the C language guarantees that all static
variables are 0-initialized.

> +
> +/* set or unset an op blocker to a BDS whether set is true or false */
> +void bdrv_op_block_action(BlockDriverState *bs, BlockOpType op,
> +                          BlockerAction action, Error *reason)
> +{

Not sure I follow that comment, since 'set' is not one of the parameter
names.


> +
> +/* Recursively set or unset an op block to a BDS tree whether set is true or
> + * false
> + */
> +void bdrv_recurse_op_block(BlockDriverState *bs, BlockOpType op,
> +                           BlockerAction action, Error *reason)

and again

> +{
> +    /* If recursion is detected simply return */
> +    if (recurse_op_bs == bs) {
> +        return;
> +    }
> +
> +    /* if we are starting recursion remeber the bs for later comparison */

s/remeber/remember/

> +    if (!recurse_op_depth) {
> +        recurse_op_bs = bs;
> +    }
> +
> +    /* try to set or unset on bs->file and bs->backing_hd first */
> +    bdrv_op_block_action(bs->file, op, action, reason);
> +    bdrv_op_block_action(bs->backing_hd, op, action, reason);
> +
> +    /* if the BDS is a filter with multiple childs ask the driver to recurse */

s/childs/children/


> +static void blkverify_recurse_op_block(BlockDriverState *bs, BlockOpType op,
> +                                       BlockerAction action, Error *reason)
> +{
> +    BDRVBlkverifyState *s = bs->opaque;
> +    bdrv_op_block_action(bs->file, op , action, reason);
> +    bdrv_op_block_action(s->test_file, op , action, reason);

s/ ,/,/ twice

> +++ b/include/block/block_int.h
> @@ -86,6 +86,11 @@ struct BlockDriver {
>       */
>      bool (*bdrv_recurse_is_first_non_filter)(BlockDriverState *bs,
>                                               BlockDriverState *candidate);
> +    /* In order to be able to recursively block operation on BDS trees filter
> +     * like quorum can implement this callback

s/trees filter/trees, a filter/

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2014-06-19 20:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-19 20:01 [Qemu-devel] [PATCH] Recursive blocker Benoît Canet
2014-06-19 20:01 ` [Qemu-devel] [PATCH] block: Make op blocker recursive Benoît Canet
2014-06-19 20:13   ` Eric Blake [this message]
2014-06-19 20:20     ` Benoît Canet
2014-06-19 20:26       ` Eric Blake
2014-06-19 20:36         ` Benoît Canet
2014-06-20  5:01       ` Fam Zheng
2014-06-20 15:30         ` Eric Blake
2014-06-21  8:53           ` Fam Zheng
2014-06-21 10:45             ` Benoît Canet
2014-06-21 15:15               ` Fam Zheng
2014-06-21 15:39                 ` Benoît Canet
2014-06-21 15:40                   ` Benoît Canet
2014-06-23  4:32                     ` Fam Zheng
2014-06-23  5:17                       ` Benoît Canet
2014-06-23  7:07                         ` Fam Zheng

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=53A34460.8010302@redhat.com \
    --to=eblake@redhat.com \
    --cc=benoit.canet@irqsave.net \
    --cc=benoit@irqsave.net \
    --cc=jcody@redhat.com \
    --cc=kwolf@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).