qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use bdrv_(p)write_syn


From: Avi Kivity
Subject: [Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use bdrv_(p)write_sync for metadata writes"
Date: Wed, 25 Aug 2010 17:00:49 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Thunderbird/3.1.2

 On 08/25/2010 04:42 PM, Anthony Liguori wrote:
On 08/25/2010 08:23 AM, Avi Kivity wrote:
 On 08/25/2010 03:46 PM, Anthony Liguori wrote:

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

btw, only supporting growth is a step backwards. Currently file-backed disks keep growing even the guest-used storage doesn't grow, since once we allocate something we never release it. But eventually guests will start using TRIM or DISCARD or however it's called, and then we can expose it and reclaim unused blocks.

You can do this in one of two ways. You can do online compaction or you can maintain a free list. Online compaction has an advantage because it does not require any operations in the fast path whereas a free list would require ordered metadata updates (must remove something from the first list before updating the l2 table) which implies a sync.

DISCARD/TRIM can queue blocks to the same preallocated block list we have to optimize allocation. New allocations can come from this list, if it grows too large we sync part of it to disk to avoid loss of a lot of free space on power fail.

At a high level, I don't think online compaction requires any specific support from an image format.


You need to know that the block is free and can be reallocated.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]