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

[Anthony Liguori <anthony@codemonkey.ws>]

On 09/08/2010 03:53 AM, Avi Kivity wrote:
>  On 09/08/2010 11:41 AM, Alexander Graf wrote:
>> On 08.09.2010, at 10:23, Avi Kivity wrote:
>>
>>> On 09/08/2010 01:27 AM, Anthony Liguori wrote:
>>>>> FWIW, L2s are 256K at the moment and with a two level table, it 
>>>>> can support 5PB of data.
>>>>
>>>> I clearly suck at basic math today.  The image supports 64TB 
>>>> today.  Dropping to 128K tables would reduce it to 16TB and 64k 
>>>> tables would be 4TB.
>>> Maybe we should do three levels then.  Some users are bound to 
>>> complain about 64TB.
>> Why 3 levels? Can't the L2 size be dynamic? Then big images get a big 
>> L2 map while small images get a smaller one.
>>
>
> Dunno, just seems more regular to me.  Image resize doesn't need to 
> relocate the L2 table in case it overflows.
>
> The overhead from three levels is an extra table, which is negligible.

It means an extra I/O request in the degenerate case whereas increasing 
the table size only impacts the size of the metadata.

A 10GB image currently has 1.2MB of metadata in QED today.  A 1TB image 
uses 128MB of metadata.  The ratio of metadata is about 0.01%.

A three level table adds an additional I/O request in order to reduce 
metadata.  But the metadata is small enough today that I don't see the 
point.

Regards,

Anthony Liguori




>   With 64K tables, the maximum image size is 32PiB, which is 14 bits 
> away from a 2TB disk, giving us about 30 years.
>