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: Avi Kivity
Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format
Date: Thu, 09 Sep 2010 09:30:51 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Thunderbird/3.1.2

 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.




reply via email to

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