All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com,
	dietmar@proxmox.com
Subject: Re: [Qemu-devel] [PATCH 0/4] export internal snapshot by qemu-nbd
Date: Thu, 18 Jul 2013 10:28:09 +0800	[thread overview]
Message-ID: <51E752B9.7030502@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130717152149.GN2458@dhcp-200-207.str.redhat.com>

于 2013-7-17 23:21, Kevin Wolf 写道:
> Am 17.07.2013 um 16:23 hat Eric Blake geschrieben:
>> On 07/17/2013 08:03 AM, Wenchao Xia wrote:
>>> This series allow user to read internal snapshot's contents without qemu-img
>>> convert. Another purpose is that, when qemu is online and have taken an
>>> internal snapshot, let user invoke qemu-nbd to do any thing on it except write.
>>>
>>> This brings two interesting issues:
>>> 1 is it safe to let qemu-nbd and qemu access that file at same time?
>>
>> Probably not, for the same reason we tell people to not use qemu-img
>> while qemu is active on a file.
>
> No, it's not. There's the built-in NBD server, but making internal
> snapshots usable with it would require some non-trivial changes in the
> block layer and the qcow2 code.
>
   What changes should be done? I think currently, it is safe except
resizing/snapshot delete, those operation can be forbidded when nbd
is running.

>>> I think it is safe, since qemu-nbd is read only. The data will be correct from
>>> qemu-nbd, if qemu does not delete that snapshot when qemu-nbd is running, and
>>> data is flushed to storage after qemu take that snapshot so that qemu-nbd
>>> would see the correct data.
>>
>> You're making assumptions that qemu won't be touching any metadata in a
>> manner in which the read-only qemu-nbd could get confused; I'm not sure
>> we are ready to make that guarantee.  I think the export has to be from
>> the running qemu process itself, rather than from a second process.
>
> I think a while ago I convinced myself that in practice it does work,
> but it's not a guarantee we're making and I won't hesitate to break the
> assumption if it's helpful for some feature.
>
   I think it can be listed out about the features that may break the
assumption, if added later, then simply forbid nbd running at that case
by user.

   This related to qcow2's specification: Do we allow another
process read an snapshot of one image while it is used, in normal
condition? It would be nice to have it as a storage software.

   My thought is that, focus more on one format for qemu, that is qcow2,
enhance it if possible instead of new format, so add some guarantee for
it may be not bad.


>>> 2 should an nbd-server exporting internal snapshot be added in qemu?
>>> I think no. Compared with driver-backup, the snapshot, or COW happens
>>> in storage level, so it allows another program to read it itself. Actually
>>> it should be OK to let another server other than qemu's host, do the
>>> export I/O job, if data is flushed.
>>
>> Unfortunately, I disagree, and think the answer to this question is yes,
>> we need to do the export from within the single qemu process, if we want
>> to guarantee safety.
>
> Agreed.
>
> Kevin
>


-- 
Best Regards

Wenchao Xia

  reply	other threads:[~2013-07-18  2:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-17 14:03 [Qemu-devel] [PATCH 0/4] export internal snapshot by qemu-nbd Wenchao Xia
2013-07-17 14:03 ` [Qemu-devel] [PATCH 1/4] snapshot: distinguish id and name in load_tmp Wenchao Xia
2013-07-17 14:03 ` [Qemu-devel] [PATCH 2/4] qemu-nbd: support internal snapshot export Wenchao Xia
2013-07-17 14:03 ` [Qemu-devel] [PATCH 3/4] qemu-nbd: add doc for " Wenchao Xia
2013-07-26  8:11   ` Stefan Hajnoczi
2013-07-29  1:57     ` Wenchao Xia
2013-07-29  7:39       ` Stefan Hajnoczi
2013-07-17 14:03 ` [Qemu-devel] [PATCH 4/4] qemu-iotests: add 057 internal snapshot export with qemu-nbd case Wenchao Xia
2013-07-17 14:23 ` [Qemu-devel] [PATCH 0/4] export internal snapshot by qemu-nbd Eric Blake
2013-07-17 15:21   ` Kevin Wolf
2013-07-18  2:28     ` Wenchao Xia [this message]
2013-07-18  7:15       ` Fam Zheng
2013-07-19  6:29   ` Wenchao Xia
2013-07-19  8:20     ` Kevin Wolf
2013-07-22  5:20   ` Wenchao Xia
2013-07-18  5:43 ` Stefan Hajnoczi
2013-07-19  9:03   ` Wenchao Xia
2013-07-19  9:19     ` Kevin Wolf
2013-07-19 10:02       ` Wenchao Xia
2013-07-22  2:10     ` Fam Zheng
2013-07-22  3:26       ` Wenchao Xia
2013-07-25  2:30 ` Wenchao Xia
2013-07-25  8:06   ` Stefan Hajnoczi
2013-07-26  2:23     ` Wenchao Xia
2013-07-26  8:20       ` Stefan Hajnoczi
2013-07-29  2:05         ` Wenchao Xia

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=51E752B9.7030502@linux.vnet.ibm.com \
    --to=xiawenc@linux.vnet.ibm.com \
    --cc=dietmar@proxmox.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.