From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49520 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtPpZ-0005bO-Om for qemu-devel@nongnu.org; Wed, 08 Sep 2010 14:57:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OtPpY-00078S-9S for qemu-devel@nongnu.org; Wed, 08 Sep 2010 14:57:13 -0400 Received: from mail-qy0-f173.google.com ([209.85.216.173]:62327) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtPpY-00078I-62 for qemu-devel@nongnu.org; Wed, 08 Sep 2010 14:57:12 -0400 Received: by qyk34 with SMTP id 34so5306264qyk.4 for ; Wed, 08 Sep 2010 11:57:11 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4C87D76D.7090804@codemonkey.ws> References: <1283767478-16740-1-git-send-email-stefanha@linux.vnet.ibm.com> <4C87D76D.7090804@codemonkey.ws> From: Blue Swirl Date: Wed, 8 Sep 2010 18:56:51 +0000 Message-ID: Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Stefan Hajnoczi , Anthony Liguori , Stefan Hajnoczi , qemu-devel@nongnu.org On Wed, Sep 8, 2010 at 6:35 PM, Anthony Liguori wro= te: > 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<=3D TABLE_NOFFSETS * TABLE_NOFFSETS * header.cluster_s= ize, >> 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 =3D 1, cluster_size =3D 4 >> bytes, =C2=A01^2 * 4^3 / 8^2 =3D 2 bytes, or is the minimum bigger? What= 's >> the minimum for cluster_size? >> > > 4k. > > The smallest image size is 1GB. =C2=A0There is no upper limit on image si= ze > because clusters can be arbitrarily large. 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. > > >>> It shouldn't matter since any header that is>=3D16 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. =C2=A0I 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. = =C2=A0We > 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?