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

[Fam Zheng <famz@redhat.com>]

On Sat, 05/23 18:51, Max Reitz wrote:
> On 22.05.2015 06:54, Fam Zheng wrote:
> >On Thu, 05/21 15:32, Fam Zheng wrote:
> >>On Thu, 05/21 15:06, Wen Congyang wrote:
> >>>On 05/21/2015 02:42 PM, Fam Zheng wrote:
> >>>>It blocks device IO.
> >>>>
> >>>>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.
> >>>>
> >>>>- backup_start
> >>>>
> >>>>   Blocking target when backup is running, unblock it.
> >>>Do you forget it?
> >>Oh I think the commit log is wrong: the target image is only written to by
> >>block job, there cannot be a device on it, so it it's similar to
> >>bdrv_set_backing_hd.
> >Correction: if it's blockdev-backup, the target could have a device, in that
> >sense it should be unblocked like block_job_create(). I'll fix it.
> 
> Really? I think it makes sense not to allow I/O on a backup target. At least
> I can't imagine a use case where you'd want to do that... But that doesn't
> necessarily mean anything, of course.

Sure that nobody other than backup job itself should write to backup target,
but it's valid to read it - image fleecing aims to export it through NBD
server. If you attach it back to guest, it is as valid a scenario, isn't it?

So at least for image fleecing, we need to either 1) split device IO blocker to
read and write and only block write on target. 2) don't add device IO blocker
at all, expect the disk's end user to take the responsibility. And I'm afraid
1) will be too complicated.

Fam