[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: KVM call agenda for Jan 25

From: Dushyant Bansal
Subject: Re: [Qemu-devel] Re: KVM call agenda for Jan 25
Date: Mon, 14 Mar 2011 20:43:31 +0530
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100713 Thunderbird/3.0.6

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:

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.

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.

3. refcount table:
qcow2->qed:we do not keep refcount structure
qed->qcow2: initialize refcount structure

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.

What do you think? Please correct me if I am making some incorrect statement.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]