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

[Anthony Liguori]

On 09/13/2010 06:28 AM, Kevin Wolf wrote:
> > Anytime you grow the freelist with qcow2, you have to write a brand new
> > freelist table and update the metadata synchronously to point to a new
> > version of it.  That means for a 1TB image, you're potentially writing
> > out 128MB of data just to allocate a new cluster.
> >      
> No. qcow2 has two-level tables.
>
> File size: 1 TB
> Number of clusters: 1 TB / 64 kB = 16 M
> Number of refcount blocks: (16 M * 2 B) / 64kB = 512
> Total size of all refcount blocks: 512 * 64kB = 32 MB
> Size of recount table: 512 * 8 B = 4 kB
>
> When we grow an image file, the refcount blocks can stay where they are,
> only the refcount table needs to be rewritten. So we have to copy a
> total of 4 kB for growing the image file when it's 1 TB in size (all
> assuming 64k clusters).
>    

Yes, I misread the code.  It is a two level table.

Even though it's 4x smaller than I previously stated, it's still quite 
large and finding a free block is an O(n) operation where n is the 
physical file size.  An fsck() on qed is also an O(n) operation where n 
is the physical file size so I still contend the two are similar in cost.

Regards,

Anthony Liguori

> The other result of this calculation is that we need to grow the
> refcount table each time we cross a 16 TB boundary. So additionally to
> being a small amount of data, it doesn't happen in practice anyway.
>
> Kevin
>