[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 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.

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