[Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use bdrv_(p)write_sync for metadata writes"

[Anthony Liguori]

On 08/25/2010 08:23 AM, Avi Kivity wrote:
>  On 08/25/2010 03:46 PM, Anthony Liguori wrote:
> > If we had another disk format that only supported growth and metadata 
> > for a backing file, can you think of another failure scenario?
>
> btw, only supporting growth is a step backwards.  Currently 
> file-backed disks keep growing even the guest-used storage doesn't 
> grow, since once we allocate something we never release it.  But 
> eventually guests will start using TRIM or DISCARD or however it's 
> called, and then we can expose it and reclaim unused blocks.

You can do this in one of two ways.  You can do online compaction or you 
can maintain a free list.  Online compaction has an advantage because it 
does not require any operations in the fast path whereas a free list 
would require ordered metadata updates (must remove something from the 
first list before updating the l2 table) which implies a sync.

At a high level, I don't think online compaction requires any specific 
support from an image format.

Regards,

Anthony Liguori