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

[Avi Kivity <avi@redhat.com>]

  On 09/08/2010 03:55 PM, Anthony Liguori wrote:

(3 levels)

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

For small images, it means a single extra read per boot (and a single 
extra write write for the lifetime of the image).  Larger images 
increase this, but it will always be a constant number of extra reads 
per boot and extra writes per image lifetime, proportional to logical 
image size.

> whereas increasing the table size only impacts the size of the metadata.

Larger L2 tables mean reduced L2 cache efficiency and longer delays 
while it is loaded.  At 100 MB/s, a 256KB L2 takes 2.5ms compared to 0.6 
ms for 64KB, perhaps not so traumatic.

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

The point is to allow really large images.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.