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

[Anthony Liguori <anthony@codemonkey.ws>]

On 08/25/2010 10:15 AM, Avi Kivity wrote:
>  On 08/25/2010 06:06 PM, Anthony Liguori wrote:
>> On 08/25/2010 09:36 AM, Avi Kivity wrote:
>>>>
>>>> If you tried to maintain a free list, then you would need to sync 
>>>> on TRIM/DISCARD which is potentially a fast path.  While a 
>>>> background task may be less efficient in the short term, it's just 
>>>> as efficient in the long term and it has the advantage of keeping 
>>>> any fast path fast.
>>>>
>>>
>>> You only need to sync when the free list size grows beyond the 
>>> amount of space you're prepared to lose on power fail.  And you may 
>>> be able to defer the background task indefinitely by satisfying new 
>>> allocations from the free list.
>>
>> Free does not mean free.  If you immediately punch a hole in the l2 
>> without doing a sync, then you're never sure whether the hole is 
>> there on disk or not.  So if you then allocate that block and put it 
>> somewhere else in another l2 table, you need to sync the previous l2 
>> change before you update the new l2.
>>
>> Otherwise you can have two l2 entries pointing to the same block 
>> after a power failure.  That's not a leak, that's a data corruption.
>
> L2 certainly needs to be updated before the block is reused.  But 
> that's not different from a file format without a free list.
>
> The batching I was referring to was only for free list management, 
> same as the allocation issue which started this thread.

Okay, yes, you can orphan blocks pro-actively and then use them for 
future allocations instead of doing active defragmentation.

I'm still not sure a free list stored in the format is all that useful 
but you could certainly implement it lazily.

Regards,

Anthony Liguori