From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36119 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P0Ai0-0008OC-MF for qemu-devel@nongnu.org; Mon, 27 Sep 2010 06:13:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1P0Ahz-0004n5-Ja for qemu-devel@nongnu.org; Mon, 27 Sep 2010 06:13:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45538) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1P0Ahz-0004mz-C4 for qemu-devel@nongnu.org; Mon, 27 Sep 2010 06:13:19 -0400 Message-ID: <4CA06E2E.7070606@redhat.com> Date: Mon, 27 Sep 2010 12:13:02 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/7] qed: Add QEMU Enhanced Disk format References: <1285256514-21138-1-git-send-email-stefanha@linux.vnet.ibm.com> In-Reply-To: <1285256514-21138-1-git-send-email-stefanha@linux.vnet.ibm.com> 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: Kevin Wolf , Anthony Liguori , qemu-devel@nongnu.org, Christoph Hellwig On 09/23/2010 05:41 PM, Stefan Hajnoczi wrote: > QEMU Enhanced Disk format is a disk image format that forgoes features > found in qcow2 in favor of better levels of performance and data > integrity. Due to its simpler on-disk layout, it is possible to safely > perform metadata updates more efficiently. > > Installations, suspend-to-disk, and other allocation-heavy I/O workloads > will see increased performance due to fewer I/Os and syncs. Workloads > that do not cause new clusters to be allocated will perform similar to > raw images due to in-memory metadata caching. > > The format supports sparse disk images. It does not rely on the host > filesystem holes feature, making it a good choice for sparse disk images > that need to be transferred over channels where holes are not supported. > > Backing files are supported so only deltas against a base image can be > stored. > > The file format is extensible so that additional features can be added > later with graceful compatibility handling. > > Internal snapshots are not supported. This eliminates the need for > additional metadata to track copy-on-write clusters. > > Compression and encryption are not supported. They add complexity and can be > implemented at other layers in the stack (i.e. inside the guest or on the > host). Encryption has been identified as a potential future extension and the > file format allows for this. > IMO the file format should be part of this patchset. Wikis are nice but they aren't a good place for authoritative documentation. -- error compiling committee.c: too many arguments to function