From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51073 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pz9TX-0005QS-Nb for qemu-devel@nongnu.org; Mon, 14 Mar 2011 11:14:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pz9TV-0000KY-IM for qemu-devel@nongnu.org; Mon, 14 Mar 2011 11:14:27 -0400 Received: from smtp2.iitd.ernet.in ([202.141.68.44]:32866) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pz9TU-00008d-Mg for qemu-devel@nongnu.org; Mon, 14 Mar 2011 11:14:25 -0400 Message-ID: <4D7E309B.6080800@cse.iitd.ac.in> Date: Mon, 14 Mar 2011 20:43:31 +0530 From: Dushyant Bansal MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: KVM call agenda for Jan 25 References: <20110124132559.GA25236@x200.localdomain> <4D3DF7EA.4010807@codemonkey.ws> <20110125115727.5f2b495e@doriath> <20110125120244.5b18863d@doriath> <4D43F0F5.10206@cse.iitd.ac.in> <4D67E9EB.7090606@cse.iitd.ac.in> <4D6975B0.4060309@cse.iitd.ac.in> <4D6C087B.90603@cse.iitd.ac.in> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org > > 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. 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. Thanks, Dushyant