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: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format
Date: Wed, 08 Sep 2010 14:19:50 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6

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




reply via email to

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