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

[Anthony Liguori]

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