From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40926 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ou1gw-0005ug-Ky for qemu-devel@nongnu.org; Fri, 10 Sep 2010 07:22:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ou1gv-0001Q5-Ih for qemu-devel@nongnu.org; Fri, 10 Sep 2010 07:22:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10329) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ou1gv-0001Pz-BD for qemu-devel@nongnu.org; Fri, 10 Sep 2010 07:22:49 -0400 Message-ID: <4C8A14F6.9040209@redhat.com> Date: Fri, 10 Sep 2010 14:22:30 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format References: <1283767478-16740-1-git-send-email-stefanha@linux.vnet.ibm.com> <4C84E738.3020802@codemonkey.ws> <4C865187.6090508@redhat.com> <4C8885BB.8020000@redhat.com> <4C891CC0.1090108@codemonkey.ws> In-Reply-To: <4C891CC0.1090108@codemonkey.ws> 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: Anthony Liguori Cc: Kevin Wolf , Stefan Hajnoczi , Stefan Hajnoczi , qemu-devel@nongnu.org On 09/09/2010 08:43 PM, Anthony Liguori wrote: >> Hm, we do have a use case for qcow2-over-lvm. I can't say it's >> something I like, but a point to consider. > > > We specifically are not supporting that use-case in QED today. > There's a good reason for it. For cluster allocation, we achieve good > performance because for L2 cluster updates, we can avoid synchronous > metadata updates (except for L1 updates). > As I've mentioned several times, if you preallocate, then you amortize that cost of keeping track of the physical image size. > We achieve synchronous metadata updates by leveraging the underlying > filesystem's metadata. The underlying filesystems are much smarter > about their metadata updates. They'll keep a journal to delay > synchronous updates and other fancy things. They only guarantee that the filesystem is consistent. A write() that extends a file may be reordered with the L2 write() that references the new cluster. Requiring fsck on unclean shutdown is very backwards for a 2010 format. > > If we tried to represent the disk size in the header, we would have to > do an fsync() on every cluster allocation. On every N cluster allocations. > > I can only imagine the use case for qcow2-over-lvm is performance. > But the performance of QED on a file system is so much better than > qcow2 that you can safely just use a file system and avoid the > complexity of qcow2 over lvm. > qcow2 over lvm is typically used on clusters. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.