From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60455 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtGPs-0002LN-IO for qemu-devel@nongnu.org; Wed, 08 Sep 2010 04:54:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OtGPr-0006Kx-9g for qemu-devel@nongnu.org; Wed, 08 Sep 2010 04:54:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21993) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtGPr-0006Ko-3Q for qemu-devel@nongnu.org; Wed, 08 Sep 2010 04:54:03 -0400 Message-ID: <4C874F22.6060802@redhat.com> Date: Wed, 08 Sep 2010 11:53:54 +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> In-Reply-To: <395D4377-00F9-4765-94C4-470BDFA1F96E@suse.de> 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: Alexander Graf Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel@nongnu.org On 09/08/2010 11:41 AM, Alexander Graf wrote: > On 08.09.2010, at 10:23, Avi Kivity wrote: > >> On 09/08/2010 01:27 AM, Anthony Liguori wrote: >>>> FWIW, L2s are 256K at the moment and with a two level table, it can support 5PB of data. >>> >>> I clearly suck at basic math today. The image supports 64TB today. Dropping to 128K tables would reduce it to 16TB and 64k tables would be 4TB. >> Maybe we should do three levels then. Some users are bound to complain about 64TB. > Why 3 levels? Can't the L2 size be dynamic? Then big images get a big L2 map while small images get a smaller one. > 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. With 64K tables, the maximum image size is 32PiB, which is 14 bits away from a 2TB disk, giving us about 30 years. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. q