From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=36147 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OtQG7-0003Lw-5c
	for qemu-devel@nongnu.org; Wed, 08 Sep 2010 15:24:40 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1OtQBW-0002FR-DP
	for qemu-devel@nongnu.org; Wed, 08 Sep 2010 15:19:55 -0400
Received: from mail-px0-f173.google.com ([209.85.212.173]:51911)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1OtQBW-0002FI-8T
	for qemu-devel@nongnu.org; Wed, 08 Sep 2010 15:19:54 -0400
Received: by pxi12 with SMTP id 12so184946pxi.4
	for <qemu-devel@nongnu.org>; Wed, 08 Sep 2010 12:19:53 -0700 (PDT)
Message-ID: <4C87E1D6.4060103@codemonkey.ws>
Date: Wed, 08 Sep 2010 14:19:50 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
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>
	<AANLkTi=ZU83BYDkgT3=mEcx1HjRiH20fT3q6HFR-uS2A@mail.gmail.com>
	<AANLkTikFbDcNU22MBXDP-+B34EA3ymQpHascM8oFiHtS@mail.gmail.com>
	<AANLkTikVbBTBAaVwbvYLrbEsQc6tPA0D6+bFW+QGjf6t@mail.gmail.com>
	<4C87D76D.7090804@codemonkey.ws>
	<AANLkTi=+TkmxAhdF9hydjw=Jy3uzbaPLXa=E8Y21K9kd@mail.gmail.com>
In-Reply-To: <AANLkTi=+TkmxAhdF9hydjw=Jy3uzbaPLXa=E8Y21K9kd@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com>, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, qemu-devel@nongnu.org

On 09/08/2010 01:56 PM, Blue Swirl wrote:
> That's a bit big, for example CD images are only 640M and there were
> smaller disks. But I guess you mean the smallest maximum size limited
> by the cluster_size etc, so the actual images may be even smaller.
>    

Yes.  The smallest image is one cluster.  The smallest cluster is 4k so 
the smallest image is 4k.

>> I don't think cluster sizes much greater than 64k actually make sense.  We
>> don't need an image format that supports>  1PB disks.
>>      
> File system developers could want to try images in exabyte ranges.
> Isn't the purpose of an image format that you can create a virtual
> disk that can appear to be bigger than the disk space needed?
>    

$ qemu-img create -f qed -o table_size=16,cluster_size=1M exabyte.qed 
$((1024*1024))T
Formatting 'exabyte.qed', fmt=qed size=1152921504606846976 
cluster_size=1048576 table_size=16 copy_on_read=off

I still contend it's insane to do, but it does work and only requires a 
1M cluster size.

Generally speaking, max image size is:

(cluster_size * table_size / 8) * (cluster_size * table_size / 8) * 
cluster_size

Or:

(2^x * 2^y / 2^3) * (2^x * 2^y / 2^3) * 2^x

valid values for y are [0...4].  Valid values for x are [12...31]

Solve for each range and you have 2^30...2^107 but you can't have an 
image > ~2^64.

There's an awful lot of flexibility with just something as simple as a 
two level table.

Regards,

Anthony Liguori