qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Fam Zheng <famz@redhat.com>, qemu-devel@nongnu.org
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
	armbru@redhat.com, qemu-block@nongnu.org, mreitz@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 10/11] blockdev: Block device IO during blockdev-backup transaction
Date: Wed, 13 May 2015 14:21:12 +0200	[thread overview]
Message-ID: <555341B8.3070604@redhat.com> (raw)
In-Reply-To: <1431538099-3286-11-git-send-email-famz@redhat.com>



On 13/05/2015 19:28, Fam Zheng wrote:
> +    state->bs = bs;
> +    error_setg(&state->blocker, "blockdev-backup in progress");
> +    bdrv_op_block(bs, BLOCK_OP_TYPE_DEVICE_IO, state->blocker);
> +
>      qmp_blockdev_backup(backup->device, backup->target,
>                          backup->sync,
>                          backup->has_speed, backup->speed,
> @@ -1696,7 +1701,6 @@ static void blockdev_backup_prepare(BlkTransactionState *common, Error **errp)
>          return;
>      }
>  
> -    state->bs = bs;

I don't understand this.  Jobs could pause/resume themselves by adding a
DEVICE_IO notifier on the targets.

However, block backups is the one job that cannot do this, because I/O
on the source triggers I/O on the target.

So if we consider this idea worthwhile, and decide that pausing device
I/O on the target should pause the block job, the backup job actually
has to prevent *adding a DEVICE_IO blocker* on the target.  This
"meta-block" is not possible in your design, which is a pity because on
the surface it looked nicer than mine.

FWIW, my original idea was:

- bdrv_pause checks if there is an operation blocker for PAUSE.  if it
is there, it fails

- otherwise, bdrv_pause invokes a notifier list if this is the outermost
call. if not the outermost call, it does nothing

- bdrv_resume does the same, but does not need a blocker

- drive-backup should block PAUSE on its target


Also, should the blockers (either DEVICE_IO in your design, or PAUSE in
mine) be included in bdrv_op_block_all.  I would say no in your case;
here is the proof:

- block-backup doesn't like DEVICE_IO blockers on the target

- block-backup calls bdrv_op_block_all on the target

- hence, bdrv_op_block_all shouldn't block DEVICE_IO


block_job_create is another suspicious caller of bdrv_op_block_all.  It
probably shouldn't block neither PAUSE nor DEVICE_IO.

Paolo

  parent reply	other threads:[~2015-05-13 12:21 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-13 17:28 [Qemu-devel] [PATCH v2 00/11] Fix transactional snapshot with virtio-blk dataplane and NBD export Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 01/11] block: Add op blocker type "device IO" Fam Zheng
2015-05-13 11:32   ` Wen Congyang
2015-05-13 12:04   ` Paolo Bonzini
2015-05-13 15:02     ` Fam Zheng
2015-05-13 15:09       ` Paolo Bonzini
2015-05-14  2:40         ` Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 02/11] block: Add op blocker notifier list Fam Zheng
2015-05-14  5:32   ` Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 03/11] block-backend: Add blk_op_blocker_add_notifier Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 04/11] virtio-blk: Move complete_request to 'ops' structure Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 05/11] virtio-blk: Don't handle output when there is "device IO" op blocker Fam Zheng
2015-05-13 10:26   ` Paolo Bonzini
2015-05-13 11:09     ` Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 06/11] nbd-server: Clear "can_read" when "device io" blocker is set Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 07/11] blockdev: Block device IO during internal snapshot transaction Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 08/11] blockdev: Block device IO during external " Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 09/11] blockdev: Block device IO during drive-backup transaction Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 10/11] blockdev: Block device IO during blockdev-backup transaction Fam Zheng
2015-05-13 11:22   ` Wen Congyang
2015-05-13 12:55     ` Fam Zheng
2015-05-14  1:12       ` Wen Congyang
2015-05-14  1:53         ` Fam Zheng
2015-05-13 12:21   ` Paolo Bonzini [this message]
2015-05-13 15:08     ` Paolo Bonzini
2015-05-13 15:34       ` Fam Zheng
2015-05-13 17:28 ` [Qemu-devel] [PATCH v2 11/11] block: Block "device IO" during bdrv_drain and bdrv_drain_all Fam Zheng
2015-05-13 10:26   ` Paolo Bonzini
2015-05-13 11:08     ` Fam Zheng
2015-05-13 11:33       ` Paolo Bonzini
2015-05-13 15:17         ` Fam Zheng
2015-05-13 15:25           ` Paolo Bonzini
2015-05-14  3:02             ` 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=555341B8.3070604@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=armbru@redhat.com \
    --cc=famz@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --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).