From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58901) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zke46-0001Ok-Fx for qemu-devel@nongnu.org; Fri, 09 Oct 2015 16:14:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zke42-0004nF-3g for qemu-devel@nongnu.org; Fri, 09 Oct 2015 16:14:54 -0400 References: <1441471439-6157-1-git-send-email-vsementsov@virtuozzo.com> <1441471439-6157-4-git-send-email-vsementsov@virtuozzo.com> <56154C89.1030506@redhat.com> <56156D05.2080701@openvz.org> <5616D1D0.6050208@redhat.com> <5617F450.9090806@redhat.com> From: Eric Blake Message-ID: <56182030.7020503@redhat.com> Date: Fri, 9 Oct 2015 14:14:40 -0600 MIME-Version: 1.0 In-Reply-To: <5617F450.9090806@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T79ukbbeLgcvre90vigFxuQn5eg5E2Qve" Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 03/17] spec: add qcow2-dirty-bitmaps specification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , John Snow , "Denis V. Lunev" , Vladimir Sementsov-Ogievskiy , qemu-devel@nongnu.org, Qemu-block Cc: kwolf@redhat.com, pbonzini@redhat.com, stefanha@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --T79ukbbeLgcvre90vigFxuQn5eg5E2Qve Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/09/2015 11:07 AM, Max Reitz wrote: >=20 > Except maybe the last bit, because "512 byte sector" basically is > meaningless when talking about a qcow2 file (which works in terms of > clusters), At KVM Forum, Kevin was mentioning an idea of adding an incompatible feature to qcow2 that would let it track per-sector dirty/zero/backing information within a cluster (things would still be allocated by cluster, but you could get fine-grained COW and other perks), by having the feature bit turn on an alternative L2 table entry representation that occupies more than 64 bits. If that happens, then qcow2 would have a bit more per-sector smarts in addition to its existing per-cluster focus. But not something that should hold up this discussion. >> We could store filenames, but networked devices and distributed >> filesystems may have interesting relative pathnames that will not rema= in >> reliable once the .qcow2 file is shuffled around or migrated, so stori= ng >> path-name references seems like a losing battle here, too. Maybe we on= ly >> have a file descriptor and no name at all -- what do we write for the >> "global identifier that uniquely identifies the data we belong to"? Is= >> it even possible? >=20 > I'd be fine with filenames. It works reasonably well for backing files,= > and it's basically the same problem there. Filenames with the escape clause of json:{...} pseudo-filenames (matching what we already allow for complex backing files) is fine by me.= >> Does anybody else have strong feelings on where we should go from here= ? >> >> (A) Argue with Max and push for qcow2-as-container >=20 > :-) >=20 >> (B) Use qcow2 for self-reference bitmaps only, use an external format >> for formats that do not support .bitmap_load or .bitmap_store >> (C) Forget about the qcow2 extension entirely, use only the new extern= al >> format >> (D) Something else? >> >> My vote is for (B), >=20 > Sounds good to me. I'm also leaning towards (B) at the moment, but could possibly still be swayed by persuasive arguments. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --T79ukbbeLgcvre90vigFxuQn5eg5E2Qve Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWGCAwAAoJEKeha0olJ0NqmWIH+gOVIlqYrB0rRBGVYWRpqi4T 273+xgms9nG7FmHc2v6qOgoYjQBE3i3c1ul+Z4rK+DlVUuXlNI6Zip8/htwjROsh y3JFlMcU/PccKE+83ceurALJux+rB+pS+QtdMCOGw9jMD1p2f5Gk29S949G0Vgcg SSbVIKFxwY2YqsLRblddussOmZ/jzgRzsFAhEqyiM431h3Q/3aRjMV9xg3mAVMIT Af56v52OtfFxrRzY/5X1bErd2aZKlfDliFsEoJqFa/Eeys18OC3zFBGezTueYpdK e0FtxYyRtPgsZnaFKYba9VN5K4XHzD4GiRXvFD20plG/sdp2TlAOkl+ghQ0RNdc= =unU0 -----END PGP SIGNATURE----- --T79ukbbeLgcvre90vigFxuQn5eg5E2Qve--