[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v6 01/13] block: Add op blocker type "device IO"

From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v6 01/13] block: Add op blocker type "device IO"
Date: Tue, 26 May 2015 16:22:10 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 21.05.2015 um 08:42 hat Fam Zheng geschrieben:
> It blocks device IO.

What I'm missing here is a description of the case that it protects
against. Blocking device I/O doesn't sound like a valid thing to want
per se, but it might be true that we need it as long as we don't have
the "real" op blockers that Jeff is working on. However, as long as you
don't say why you want that, I can't say whether it's true or not.

And of course, it doesn't block anything yet after this patch, it's just
set or cleared without any effect. In fact, it seems that even at the
end of the series, there is no bdrv_op_is_blocked() call that checks for
BLOCK_OP_TYPE_DEVICE_IO. Is this intentional?
> All bdrv_op_block_all/blk_op_block_all callers are taken care of:
> - virtio_blk_data_plane_create
> - virtio_scsi_hotplug
>   Device creation, unblock it.
> - bdrv_set_backing_hd
>   Backing hd is not used by device, so blocking is OK.

If the backing file becomes the active layer after committing,
bdrv_swap() will keep the blockers of the overlay, so that the image
doesn't have the device I/O blocker any more. Correct?

> - backup_start
>   Blocking target when backup is running, unblock it.
> - mirror_complete
>   Blocking s->to_replace until mirror_exit, OK.
> - block_job_complete
>   The block job may be long running. Unblock it.
> - init_blk_migration
>   The block migration may be long running, Unblock it.
> Signed-off-by: Fam Zheng <address@hidden>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]