From: Wen Congyang <wency@cn.fujitsu.com>
To: Eric Blake <eblake@redhat.com>,
qemu devel <qemu-devel@nongnu.org>, Fam Zheng <famz@redhat.com>,
Max Reitz <mreitz@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
zhanghailiang <zhang.zhanghailiang@huawei.com>,
qemu block <qemu-block@nongnu.org>,
Jiang Yunhong <yunhong.jiang@intel.com>,
Dong Eddie <eddie.dong@intel.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Michael R. Hines" <mrhines@linux.vnet.ibm.com>,
Gonglei <arei.gonglei@huawei.com>,
Yang Hongyang <yanghy@cn.fujitsu.com>
Subject: Re: [Qemu-devel] [PATCH 04/16] block: Allow references for backing files
Date: Wed, 9 Sep 2015 16:51:56 +0800 [thread overview]
Message-ID: <55EFF32C.1000604@cn.fujitsu.com> (raw)
In-Reply-To: <55E744E6.5040502@redhat.com>
On 09/03/2015 02:50 AM, Eric Blake wrote:
> On 09/02/2015 02:51 AM, Wen Congyang wrote:
>> Usage:
>> -drive file=xxx,id=Y, \
>> -drive file=xxxx,id=X,backing.backing_reference=Y
>>
>> It will create such backing chain:
>> {virtio-blk dev 'Y'} {virtio-blk dev 'X'}
>> | |
>> | |
>> v v
>>
>> [base] <- [mid] <- ( Y ) <----------------- ( X )
>
> This makes any changes to 'Y' have unspecified effects on 'X'. While we
> may have a valid reason to use a backing BDS in more than one chain, I
> seriously doubt anyone will ever want to have two guest-visible -drive's
> that are both read-write where one can corrupt the other. I can totally
> see the point of having BDS 'Y' exist for checkpoints or some other
> non-guest-visible action, so I'm not saying this patch is wrong, just
> that the commit message is picking a poor example of how it would be used.
Sorry, this graph is wrong. virtio-blk dev 'Y' can not use the BDS Y if it
is referenced by X. That is why I need patch 1 and 2.
Thanks
Wen Congyang
>
>>
>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>> Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
>> Signed-off-by: Gonglei <arei.gonglei@huawei.com>
>> ---
>> block.c | 39 +++++++++++++++++++++++++++++++++++----
>> include/block/block.h | 1 +
>> 2 files changed, 36 insertions(+), 4 deletions(-)
>>
>> diff --git a/block.c b/block.c
>> index d02d9e9..f93c50d 100644
>> --- a/block.c
>> +++ b/block.c
>> @@ -1179,6 +1179,7 @@ out:
>> }
>>
>> #define ALLOW_WRITE_BACKING_FILE "allow-write-backing-file"
>> +#define BACKING_REFERENCE "backing_reference"
>
> Why the inconsistency in '-' vs. '_'? I'd stick with dash here.
>
>> static QemuOptsList backing_file_opts = {
>> .name = "backing_file",
>> .head = QTAILQ_HEAD_INITIALIZER(backing_file_opts.head),
>> @@ -1188,6 +1189,11 @@ static QemuOptsList backing_file_opts = {
>> .type = QEMU_OPT_BOOL,
>> .help = "allow write to backing file",
>> },
>> + {
>> + .name = BACKING_REFERENCE,
>> + .type = QEMU_OPT_STRING,
>> + .help = "reference to the exsiting BDS",
>
> s/exsiting/existing/
>
> But why do we need this? In qapi, BlockdevOptionsGenericCOWFormat
> already has '*backing':'BlockdevRef', and BlockdevRef already has a
> choice between 'definition' (object) and 'reference' (string). Or is
> this just a matter of teaching the command line to do what QMP can
> already do? In which case, wouldn't:
>
> -drive file=xxx,id=Y, -drive file=xxxx,id=X,backing=Y
>
> be the natural mapping of 'backing' being a string rather than a dictionary?
>
next prev parent reply other threads:[~2015-09-09 8:52 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-02 8:51 [Qemu-devel] [PATCH 00/16] Block replication for continuous checkpoints Wen Congyang
2015-09-02 8:51 ` [Qemu-devel] [PATCH 01/16] introduce a new API to enable/disable attach device model Wen Congyang
2015-09-02 15:37 ` Eric Blake
2015-09-07 1:27 ` Wen Congyang
2015-09-02 8:51 ` [Qemu-devel] [PATCH 02/16] introduce a new API to check if blk is attached Wen Congyang
2015-09-02 15:40 ` Eric Blake
2015-09-02 8:51 ` [Qemu-devel] [PATCH 03/16] allow writing to the backing file Wen Congyang
2015-09-02 16:06 ` Eric Blake
2015-09-09 9:19 ` Wen Congyang
2015-09-02 8:51 ` [Qemu-devel] [PATCH 04/16] block: Allow references for backing files Wen Congyang
2015-09-02 18:50 ` Eric Blake
2015-09-09 8:51 ` Wen Congyang [this message]
2015-09-02 8:51 ` [Qemu-devel] [PATCH 05/16] introduce a new API qemu_opts_absorb_qdict_by_index() Wen Congyang
2015-09-02 19:01 ` Eric Blake
2015-09-07 2:18 ` Wen Congyang
2015-09-02 8:51 ` [Qemu-devel] [PATCH 06/16] quorum: allow ignoring child errors Wen Congyang
2015-09-02 16:30 ` Eric Blake
2015-09-07 3:40 ` Wen Congyang
2015-09-07 16:56 ` Dr. David Alan Gilbert
2015-09-08 0:46 ` Wen Congyang
2015-09-02 8:51 ` [Qemu-devel] [PATCH 07/16] Backup: clear all bitmap when doing block checkpoint Wen Congyang
2015-09-02 14:10 ` Jeff Cody
2015-09-02 8:51 ` [Qemu-devel] [PATCH 08/16] block: make bdrv_put_ref_bh_schedule() as a public API Wen Congyang
2015-09-02 8:51 ` [Qemu-devel] [PATCH 09/16] Allow creating backup jobs when opening BDS Wen Congyang
2015-09-02 14:12 ` Jeff Cody
2015-09-02 8:51 ` [Qemu-devel] [PATCH 10/16] docs: block replication's description Wen Congyang
2015-09-02 20:41 ` Eric Blake
2015-09-09 8:22 ` Wen Congyang
2015-09-02 8:51 ` [Qemu-devel] [PATCH 11/16] Add new block driver interfaces to control block replication Wen Congyang
2015-09-02 16:33 ` Eric Blake
2015-09-09 9:24 ` Wen Congyang
2015-09-25 6:14 ` Wen Congyang
2015-09-02 8:51 ` [Qemu-devel] [PATCH 12/16] skip nbd_target when starting " Wen Congyang
2015-09-02 8:51 ` [Qemu-devel] [PATCH 13/16] quorum: implement block driver interfaces for " Wen Congyang
2015-09-02 8:51 ` [Qemu-devel] [PATCH 14/16] Implement new driver " Wen Congyang
2015-09-02 8:51 ` [Qemu-devel] [PATCH 15/16] support replication driver in blockdev-add Wen Congyang
2015-09-02 16:36 ` Eric Blake
2015-09-09 8:27 ` Wen Congyang
2015-09-02 8:51 ` [Qemu-devel] [PATCH 16/16] Add a new API to start/stop replication, do checkpoint to all BDSes Wen Congyang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55EFF32C.1000604@cn.fujitsu.com \
--to=wency@cn.fujitsu.com \
--cc=arei.gonglei@huawei.com \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=eddie.dong@intel.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=mrhines@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=yanghy@cn.fujitsu.com \
--cc=yunhong.jiang@intel.com \
--cc=zhang.zhanghailiang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).