qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format


From: Blue Swirl
Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format
Date: Wed, 8 Sep 2010 18:56:51 +0000

On Wed, Sep 8, 2010 at 6:35 PM, Anthony Liguori <address@hidden> wrote:
> 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.

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>=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.

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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]