From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=58481 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OtPUh-0004R5-99
	for qemu-devel@nongnu.org; Wed, 08 Sep 2010 14:35:40 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1OtPUg-0003cU-1J
	for qemu-devel@nongnu.org; Wed, 08 Sep 2010 14:35:39 -0400
Received: from mail-vw0-f45.google.com ([209.85.212.45]:42562)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1OtPUf-0003cJ-UM
	for qemu-devel@nongnu.org; Wed, 08 Sep 2010 14:35:37 -0400
Received: by vws19 with SMTP id 19so346062vws.4
	for <qemu-devel@nongnu.org>; Wed, 08 Sep 2010 11:35:36 -0700 (PDT)
Message-ID: <4C87D76D.7090804@codemonkey.ws>
Date: Wed, 08 Sep 2010 13:35:25 -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>
In-Reply-To: <AANLkTikVbBTBAaVwbvYLrbEsQc6tPA0D6+bFW+QGjf6t@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>, Anthony Liguori <aliguori@us.ibm.com>, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, qemu-devel@nongnu.org

On 09/08/2010 01:24 PM, Blue Swirl wrote:
> Based on these:
> #define TABLE_NOFFSETS (table_size * cluster_size / sizeof(uint64_t))
> header.image_size<= TABLE_NOFFSETS * TABLE_NOFFSETS * header.cluster_size,
> the maximum image size equals to table_size^2 * cluster_size^3 /
> sizeof(uint64_t)^2. Is the squaring and cubing of the terms
> beneficial? I mean, the size scales up fast to unusable numbers,
> whereas with a more linear equation (for example, allow different L1
> and L2 sizes), more values could be actually usable. Again, I'm not
> sure if this matters at all.
>
> I think the minimum size should be table_size = 1, cluster_size = 4
> bytes,  1^2 * 4^3 / 8^2 = 2 bytes, or is the minimum bigger? What's
> the minimum for cluster_size?
>    

4k.

The smallest image size is 1GB.  There is no upper limit on image size 
because clusters can be arbitrarily large.


>> It shouldn't matter since any header that is>=16 TB means something
>> mutated, escaped the lab, and is terrorizing the world as a qed
>> monster image.
>>      
> In the Wiki version this has changed to header_size in clusters. With
> 2GB clusters, there will be some wasted bits.
>    

2GB clusters would waste an awful lot of space regardless.  I don't 
think it's useful to have clusters that large.

> By the way, perhaps cluster_size of 0 should mean 4GB? Or maybe all
> sizes should be expressed as an exponent to 2, then 16 bits would
> allow cluster sizes up to 2^64?
>    

I don't think cluster sizes much greater than 64k actually make sense.  
We don't need an image format that supports > 1PB disks.

Regards,

Anthony Liguori