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

[Avi Kivity <avi@redhat.com>]

  On 08/25/2010 04:42 PM, Anthony Liguori wrote:
> 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.

DISCARD/TRIM can queue blocks to the same preallocated block list we 
have to optimize allocation.  New
allocations can come from this list, if it grows too large we sync part 
of it to disk to avoid loss of a lot of free space on power fail.

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

You need to know that the block is free and can be reallocated.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.