[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 02:14 AM, Avi Kivity wrote:
>> If (c) happens before (b), then we've created an extent that's 
>> attached to a table with a zero reference count.  This is a corrupt 
>> image.
>>
>
>
> If the only issue is new block allocation, it can be easily solved.

Technically, I believe there are similar issues around creating 
snapshots but I don't think we care.

>   Instead of allocating exactly the needed amount of blocks, allocate 
> a large extent and hold them in memory.

So you're suggesting that we allocate a bunch of blocks, update the ref 
count table so that they are seen as allocated even though they aren't 
attached to an l1 table?

>   The next allocation can then be filled from memory, so the 
> allocation sync is amortized over many blocks.  A power fail will leak 
> the preallocated blocks, losing some megabytes of address space, but 
> not real disk space.

It's a clever idea, but it would lose real disk space which is probably 
not a huge issue.

>> Let's consider if we eliminate the reference count table which means 
>> eliminating internal snapshots.
>>
>> 1) guest submits write request
>> 2) allocate extent
>> 3) write data to disk (a)
>> 4) write (a) completes
>> 5) write extent table (c)
>> 6) write (c) completes
>> 7) complete guest write request
>>
>> If this all happens in order and we lose power, we just leak a 
>> block.  It means we need a periodic fsck.
>>
>> If (c) completes before (a), then it means that the image is not 
>> corrupted but data gets lost.  This is okay based on the guest contract.
>>
>> And that's it.  There is no scenario where the disk is corrupted.
>
> _if_ that's the only failure mode.

If we had another disk format that only supported growth and metadata 
for a backing file, can you think of another failure scenario?

Regards,

Anthony Liguori