From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzSeW-0006cd-Op for qemu-devel@nongnu.org; Wed, 17 Jul 2013 10:24:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzSeU-0001BI-NC for qemu-devel@nongnu.org; Wed, 17 Jul 2013 10:24:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43414) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzSeU-0001B4-Eu for qemu-devel@nongnu.org; Wed, 17 Jul 2013 10:24:22 -0400 Message-ID: <51E6A8D3.4050406@redhat.com> Date: Wed, 17 Jul 2013 08:23:15 -0600 From: Eric Blake MIME-Version: 1.0 References: <1374069835-14287-1-git-send-email-xiawenc@linux.vnet.ibm.com> In-Reply-To: <1374069835-14287-1-git-send-email-xiawenc@linux.vnet.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2VOBRNAVQXRTWXJXEVRLW" 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: Wenchao Xia Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, dietmar@proxmox.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2VOBRNAVQXRTWXJXEVRLW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/17/2013 08:03 AM, Wenchao Xia wrote: > This series allow user to read internal snapshot's contents without qem= u-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 excep= t write. >=20 > 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. > I think it is safe, since qemu-nbd is read only. The data will be corre= ct from > qemu-nbd, if qemu does not delete that snapshot when qemu-nbd is runnin= g, and > data is flushed to storage after qemu take that snapshot so that qemu-n= bd > 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. >=20 > 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. Actua= lly > 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. >=20 > 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. >=20 > More: > With this patch and previous qcow2 snapshot at block device level, I th= ink > export/import/backup solution around qcow2, is nearly complete at qemu'= s > level. It can do similar things as backing chain but with better perfor= mance, > Some small optimization place are left: >=20 > 1 compare two snapshot's data to get the diff with help of qcow2's L1/L= 2 table. > 2 convertion between external snapshot and internal snapshot. >=20 > 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 >=20 > 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 >=20 > 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 >=20 >=20 >=20 >=20 >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2VOBRNAVQXRTWXJXEVRLW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJR5qjTAAoJEKeha0olJ0NqGY4H/1B5Cduq5YhWysF1aKbzA0rf M4q9iTE0OOE1RrsoQxdM6Uxk2TRi6Ww/iedibKeg+cZQNEc2C7tZpAVc8qbjLzE+ YZc1jm09HkGErleVgKYQ+txH3IWEd3zlA+Kk2sUSxK2uKgUGC685xSLrovA0NqTK YClHST1UPxfO4YDxnAqKtFCe3x6FTHm4obL0mHzfDuHzh6BKR3P3b2wzpjPR6FOL ZhB3vTACwudQ5NZCG5olp5yTYwx8fzbY95jSVfpeb6ODIxMXKIkW1jMFC3M2FjsM XAcR3dWxSeH/uA/Akc7Urmwu/EYjhRiNbGjWEasByKYvxq8FiyDJvm3GoJlY0tY= =Aq/e -----END PGP SIGNATURE----- ------enig2VOBRNAVQXRTWXJXEVRLW--