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

[Avi Kivity]

 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.