qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH 1/3] block: add target-id option to drive-ba


From: Fam Zheng
Subject: Re: [Qemu-devel] [RFC PATCH 1/3] block: add target-id option to drive-backup QMP command
Date: Fri, 28 Jun 2013 10:17:31 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

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