[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [RFC] Intermediate block mirroring
From: |
Alberto Garcia |
Subject: |
Re: [Qemu-block] [RFC] Intermediate block mirroring |
Date: |
Thu, 03 May 2018 14:33:24 +0200 |
User-agent: |
Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu) |
On Thu 03 May 2018 02:22:41 PM CEST, Kevin Wolf wrote:
> Am 02.05.2018 um 16:12 hat Max Reitz geschrieben:
>> On 2018-05-02 15:07, Alberto Garcia wrote:
>> > Were the (more or less) exact requirements of QMP blockdev-reopen
>> > discussed? How is it different from qemu-io's "reopen" command? What are
>> > the options that you can and can not change?
>>
>> I can't quite remember, I'm afraid. I think it was supposed to be
>> pretty much qemu-io's reopen (so just bdrv_reopen()). I suppose you
>> cannot change the driver (obviously) or probably the node name, because
>> either would result in the node being replaced by a completely new one.
>>
>> Other than that, it probably depends on what the block driver supports,
>> but ideally you should be able to change everything.
>
> Honestly the design of bdrv_reopen() is quite broken because of the way
> it tries to maintain old options if they aren't specified, and guesses
> what you might mean when you add flags to the mix. The exact semantics
> are quite complicated and I'd rather avoid them in a stable API.
>
> A clean QMP command would probably apply the same defaults as
> blockdev-add, so you just get to specify the full options again.
Ok, so the end result would be more or less equivalent to "open the new
block device with blockdev-add and the user-specified options, then
replace the old one with the new one", but implemented with reopen
instead of open + replace.
Berto