On 26.05.2015 16:22, Kevin Wolf wrote:
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?
Probably yes, because patches 2 and 3 introduce a notifier for when op
blockers are set up and removed. This is used by virtio-blk and
virtio-scsi to pause and unpause device I/O, respectively.
Max
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 <f...@redhat.com>
Kevin