[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 03:46 PM, Anthony Liguori wrote:
> 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?

Yes.  Like malloc() will ask the OS for more memory that the 20-byte 
allocation you've requested.

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

Not real disk space since no pwrite() would ever touch the disk.  If the 
image were copied, _then_ we'd lose the disk space, if the copy command 
and filesystem don't optimize zeros away.

>>>
>>> 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?
>

I can't think of one, but that's not saying much.

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