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

[Anthony Liguori]

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.