Am 14.03.2011 16:13, schrieb Dushyant Bansal: >> >> Nice that qemu-img convert isn't that far out by default on raw :). >> >> About Google Summer of Code, I have posted my take on applying and >> want to share that with you and qemu-devel: >> >> http://blog.vmsplice.net/2011/03/advice-for-students-applying-to-google.html >> > Thanks for sharing your experiences. > > After reading about qcow2 and qed and how they organize data (thanks to > the newly added qcow2 doc and discussions on the mailing list), this is > what I understand. > > So, the main difference between qed and qcow2 is the absence of > reference count structure in qed(means less meta data). > It improves performance due to: > 1. For write operations, less or no metadata to update. > 2. Data write and metadata write can be in any order > > This also means these features are no longer supported: > 1. Internal snapshots, > 2. CPU/device state snapshots, > 3. Compression, > 4. Encryption > > Now, coming to qed<-->qcow2 conversion, I want to clarify some things. > > 1. header_size: variable in qed, equals to cluster size in qcow2: > When will it be larger than 1 cluster in qed? So, what will happen to > that extra data on qed->qcow2 conversion.
If you have an feature that is used in the original image, but cannot be represented in the new format, I think you should just get an error. > 2. L2 table size: equals to L1 table size in qed, equals to cluster size > in qcow2: > we need to take it into account during conversion. Right. I think we'll have to rewrite all of the metadata. I wonder if we can manage to have a nice block driver interface for in-place image conversions so that we don't only get a qed<->qcow2 converter, but also can implement the interface in e.g. VMDK and get VMDK<->qcow2 and VMDK<->qed as well. > 3. refcount table: > qcow2->qed:we do not keep refcount structure > qed->qcow2: initialize refcount structure Yes, refcounts can be rebuilt after the mapping has been converted. > So, a qcow2->qed->qcow2 conversion means if earlier, qcow2 image was > using additional features{1-4}, all information related to that will be > lost. We shouldn't lose anything but just abort if a conversion isn't possible. The user can still use qemu-img convert for the more complicated cases, for example for removing encryption or compression. Kevin