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?
>>
> 
> 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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org