[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
Re: [Qemu-devel] [RFC PATCH 1/3] block: add target-id option to drive-backup QMP command
Thu, 27 Jun 2013 13:40:31 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
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.
[Qemu-devel] [RFC PATCH 2/3] block: assign backing relationship in drive-backup, Fam Zheng, 2013/06/26
[Qemu-devel] [RFC PATCH 3/3] nbd: don't get ref if bs has no drive, Fam Zheng, 2013/06/26
Re: [Qemu-devel] [RFC PATCH 0/3] Point-in-time snapshot exporting with drive-backup, Paolo Bonzini, 2013/06/26