From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHgCq-0005qv-Q9 for qemu-devel@nongnu.org; Wed, 13 Aug 2014 17:35:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XHgCl-0001HF-FL for qemu-devel@nongnu.org; Wed, 13 Aug 2014 17:35:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46079) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHgCl-0001H7-62 for qemu-devel@nongnu.org; Wed, 13 Aug 2014 17:35:35 -0400 Message-ID: <53EBDA24.9070303@redhat.com> Date: Wed, 13 Aug 2014 15:35:32 -0600 From: Eric Blake MIME-Version: 1.0 References: <20140813155415.GE3701@noname.redhat.com> <20140813183236.GA2469@noname.redhat.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jk5lHUTtK8nPIWgBm1UEJC3kWoCPNWpkq" Subject: Re: [Qemu-devel] disk image: self-organized format or raw file List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Xingbo Wu , Kevin Wolf Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jk5lHUTtK8nPIWgBm1UEJC3kWoCPNWpkq Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/13/2014 03:04 PM, Xingbo Wu wrote: >>> I read several messages from this thread: "[RFC] qed: Add QEMU >>> Enhanced Disk format". To my understanding, if the new format can be >>> acceptable to the community: >>> It needs to retain all the key features provided by qcow2, >>> especially for compression, encryption, and internal snapshot, as >>> mentioned in that thread. Encryption in qcow2 is currently a joke, that no one in their right mind should be relying on. If your new format approaches encryption in a cryptographically sound manner, then your format might be considered better even without beating qcow2 in benchmarks. But from the sound of this thread, you aren't out to improve encrypted images. And even if you ARE hoping to improve encrypted images, it might STILL be better to investigate how to enhance qcow2 to do a cryptographically sound encryption (the idea floated on the list is to let qcow2 do LUKS encryption of the guest-visible payload, while still leaving the metadata unencrypted), rather than trying to do a completely new format. >>> And, needless to say, it must run faster. >>> >>> Yes I agree it's at least a subset of the homework one need to do >>> before selling the new format to the community. >> >> So your goal is improved performance? >> >=20 > Yes if performance is not improved I won't spend more time on it :). > I believe it's gonna be very difficult. Good luck if you are willing to try it. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --jk5lHUTtK8nPIWgBm1UEJC3kWoCPNWpkq 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJT69okAAoJEKeha0olJ0Nqz0AH+gK4AhcImoOg/rV5O5aTD8RE mHrdz2cmGDUnSzCxhMf15wQ0HiQaejT0jSKHfumA+T8T9ARGX9iNjhWPkF6+Fqzj HFdqTL/2hUfUChqK+jZLyliMM3R0uHXDhnA6By7Ao/C1/02OqZxViapHV7OV0Lpj TfBTDDtNWbihQVpDvKTL1QRjWIGV3OyCeJhNDafypvPDHUtqJrtkRhouNjVERqSV 6xIk1LvbtYZhQxRZWrEDuzhAugH84+p0f80ckQuwlqU5lcyIz9jIjnwotFWJb0BL t8uIRlw+26XqYg1nhgX/z+Rej4NSLF8FCVlobjzNNM89PVW8SliIRNKtftwhfjI= =y1yD -----END PGP SIGNATURE----- --jk5lHUTtK8nPIWgBm1UEJC3kWoCPNWpkq--