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.
