From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37490 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtaiB-0004JI-IP for qemu-devel@nongnu.org; Thu, 09 Sep 2010 02:34:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Otaew-0003YX-Ku for qemu-devel@nongnu.org; Thu, 09 Sep 2010 02:30:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40170) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Otaew-0003YR-DI for qemu-devel@nongnu.org; Thu, 09 Sep 2010 02:30:58 -0400 Message-ID: <4C887F1B.3080507@redhat.com> Date: Thu, 09 Sep 2010 09:30:51 +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> <4C865CFE.7010508@codemonkey.ws> <4C8663C4.1090508@redhat.com> <4C866773.2030103@codemonkey.ws> <4C86BC6B.5010809@codemonkey.ws> <4C874812.9090807@redhat.com> <395D4377-00F9-4765-94C4-470BDFA1F96E@suse.de> <4C874F22.6060802@redhat.com> <4C8787B6.2070907@codemonkey.ws> In-Reply-To: <4C8787B6.2070907@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 , qemu-devel@nongnu.org, Alexander Graf , Stefan Hajnoczi On 09/08/2010 03:55 PM, Anthony Liguori wrote: (3 levels) >> Dunno, just seems more regular to me. Image resize doesn't need to >> relocate the L2 table in case it overflows. >> >> The overhead from three levels is an extra table, which is negligible. > > > It means an extra I/O request in the degenerate case For small images, it means a single extra read per boot (and a single extra write write for the lifetime of the image). Larger images increase this, but it will always be a constant number of extra reads per boot and extra writes per image lifetime, proportional to logical image size. > whereas increasing the table size only impacts the size of the metadata. Larger L2 tables mean reduced L2 cache efficiency and longer delays while it is loaded. At 100 MB/s, a 256KB L2 takes 2.5ms compared to 0.6 ms for 64KB, perhaps not so traumatic. > > A 10GB image currently has 1.2MB of metadata in QED today. A 1TB > image uses 128MB of metadata. The ratio of metadata is about 0.01%. > > A three level table adds an additional I/O request in order to reduce > metadata. But the metadata is small enough today that I don't see the > point. The point is to allow really large images. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.