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.
