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: Anthony Liguori
Subject: [Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use bdrv_(p)write_sync for metadata writes"
Date: Wed, 25 Aug 2010 10:21:47 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6

On 08/25/2010 10:15 AM, Avi Kivity wrote:
 On 08/25/2010 06:06 PM, Anthony Liguori wrote:
On 08/25/2010 09:36 AM, Avi Kivity wrote:

If you tried to maintain a free list, then you would need to sync on TRIM/DISCARD which is potentially a fast path. While a background task may be less efficient in the short term, it's just as efficient in the long term and it has the advantage of keeping any fast path fast.


You only need to sync when the free list size grows beyond the amount of space you're prepared to lose on power fail. And you may be able to defer the background task indefinitely by satisfying new allocations from the free list.

Free does not mean free. If you immediately punch a hole in the l2 without doing a sync, then you're never sure whether the hole is there on disk or not. So if you then allocate that block and put it somewhere else in another l2 table, you need to sync the previous l2 change before you update the new l2.

Otherwise you can have two l2 entries pointing to the same block after a power failure. That's not a leak, that's a data corruption.

L2 certainly needs to be updated before the block is reused. But that's not different from a file format without a free list.

The batching I was referring to was only for free list management, same as the allocation issue which started this thread.

Okay, yes, you can orphan blocks pro-actively and then use them for future allocations instead of doing active defragmentation.

I'm still not sure a free list stored in the format is all that useful but you could certainly implement it lazily.

Regards,

Anthony Liguori




reply via email to

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