On Thu, 06/27 13:40, Paolo Bonzini wrote:
> Il 27/06/2013 13:37, Fam Zheng ha scritto:
> >>> > >
> >>> > > Yes, this makes me realize that ref count it not a solution to retire
> >>> > > bs->in_use, because we can't tell if drive-del or block-resize is safe
> >>> > > with only reference number. But I can't think of two situations to
> >>> > > deny
> >>> > > different subsets of commands, shouldn't a general blocker, like
> >>> > > in_use
> >>> > > does, be good enough?
> >> >
> >> > For example, right now nbd-server-add does not check bdrv_in_use. But
> >> > shrinking a device that is exposed via NBD could be surprising to the
> >> > NBD clients.
> >> >
> > So it seems to me that both block job and nbd server have the same
> > restriction on device: don't resize, and notify on close. So my question
> > is if we implement bdrv_add_command_blocker(), do the callers still need to
> > distinguish what actions to block, or it's generally to block all the
> > actions those change the device parameter?
>
> It would be a good start to have a list of things that are setting and
> checking bdrv_in_use. Then we can make a matrix.
>
Grapping the code and get:
Commands fail with -EBUSY if bdrv_in_use():
bdrv_commit()
bdrv_truncate()
external_snapshot_prepare()
eject_device()
drive_del()
drive_mirror()
block_job_create()
Commands to set bdrv in_use to 1:
init_blk_migration()
block_job_create()
virtio_blk_data_plane_create()
--
Fam
