From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V04CM-00038E-Pa for qemu-devel@nongnu.org; Fri, 19 Jul 2013 02:29:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V04CL-0006qa-EU for qemu-devel@nongnu.org; Fri, 19 Jul 2013 02:29:50 -0400 Received: from e23smtp02.au.ibm.com ([202.81.31.144]:50752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V04CK-0006qH-QD for qemu-devel@nongnu.org; Fri, 19 Jul 2013 02:29:49 -0400 Received: from /spool/local by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 19 Jul 2013 16:19:26 +1000 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [9.190.235.21]) by d23dlp03.au.ibm.com (Postfix) with ESMTP id CD777357804E for ; Fri, 19 Jul 2013 16:29:40 +1000 (EST) Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r6J6TUpU6422798 for ; Fri, 19 Jul 2013 16:29:31 +1000 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r6J6Te0g029669 for ; Fri, 19 Jul 2013 16:29:40 +1000 Message-ID: <51E8DCC4.3080508@linux.vnet.ibm.com> Date: Fri, 19 Jul 2013 14:29:24 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <1374069835-14287-1-git-send-email-xiawenc@linux.vnet.ibm.com> <51E6A8D3.4050406@redhat.com> In-Reply-To: <51E6A8D3.4050406@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 0/4] export internal snapshot by qemu-nbd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, dietmar@proxmox.com 于 2013-7-17 22:23, Eric Blake 写道: > 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. > For external case, or backing chain, qemu-nbd export while qemu is active, do you think it is OK? base->imageA qemu-nbd export base qemu use imageA. >> 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. > >> >> 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. > >> >> Next step: >> As demonstrated before, an explict API should be added, which make sure >> all I/O request is flushed and sent to underlining storage, and cache >> is sync if it is writeback type. So at qemu level, we can make sure >> no request is left behind, before qemu-nbd start. That API should >> also benefit 3rd party block snapshot solution, such as LVM2. >> >> More: >> With this patch and previous qcow2 snapshot at block device level, I think >> export/import/backup solution around qcow2, is nearly complete at qemu's >> level. It can do similar things as backing chain but with better performance, >> Some small optimization place are left: >> >> 1 compare two snapshot's data to get the diff with help of qcow2's L1/L2 table. >> 2 convertion between external snapshot and internal snapshot. >> >> This series need following series applied first: >> [PATCH V5 0/8] add internal snapshot support at block device level >> http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg01831.html >> >> Wenchao Xia (4): >> 1 snapshot: distinguish id and name in load_tmp >> 2 qemu-nbd: support internal snapshot export >> 3 qemu-nbd: add doc for internal snapshot export >> 4 qemu-iotests: add 057 internal snapshot export with qemu-nbd case >> >> block/qcow2-snapshot.c | 16 +++++++- >> block/qcow2.h | 5 ++- >> block/snapshot.c | 37 ++++++++++++++++++- >> include/block/block_int.h | 4 ++- >> include/block/snapshot.h | 4 ++- >> qemu-img.c | 7 +++- >> qemu-nbd.c | 56 ++++++++++++++++++++++++++++- >> qemu-nbd.texi | 3 ++ >> tests/qemu-iotests/057 | 87 ++++++++++++++++++++++++++++++++++++++++++++ >> tests/qemu-iotests/057.out | 26 +++++++++++++ >> tests/qemu-iotests/group | 1 + >> 11 files changed, 237 insertions(+), 9 deletions(-) >> create mode 100755 tests/qemu-iotests/057 >> create mode 100644 tests/qemu-iotests/057.out >> >> >> >> >> > -- Best Regards Wenchao Xia