qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format


From: Avi Kivity
Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format
Date: Fri, 10 Sep 2010 16:56:33 +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 09/10/2010 04:39 PM, Anthony Liguori wrote:
On 09/10/2010 07:47 AM, Avi Kivity wrote:
Then, with a clean base that takes on board the lessons of existing
formats it is much easier to innovate.  Look at the image streaming,
defragmentation, and trim ideas that are playing out right now.  I
think the reason we haven't seen them before is because the effort and
the baggage of doing them is too great.  Sure, we maintain existing
formats but I don't see active development pushing virtualized storage
happening.


The same could be said about much of qemu. It is an old code base that wasn't designed for virtualization. Yet we maintain it and develop it because compatibility is king.

(as an aside, qcow2 is better positioned for TRIM support than qed is)

You're hand waving to a dangerous degree here :-)

TRIM in qcow2 would require the following sequence:

1) remove cluster from L2 table
2) sync()
3) reduce cluster reference count
4) sync()

TRIM needs to be fast so this is not going to be acceptable. How do you solve it?


Batching.  Of course, you don't reuse the cluster until you've synced.

Note the whole thing can happen in the background. You issue the sync, but the waiting isn't exposed to the guest.

Freeing and allocation are both easy to batch since they're not guest visible operation.

For QED, TRIM requires:

1) remove cluster from L2 table
2) sync()

In both cases, I'm assuming we lazily write the free list and have a way to detect unclean mounts.

You don't have a free list in qed.

Unclean mounts require an fsck() and both qcow2 and qed require it.

qcow2 does not require an fsck (and neither does qed if it properly preallocates).

You can drop the last sync() in both QEDand qcow2 by delaying the sync() until you reallocate the cluster. If you sync() for some other reason before then, you can avoid it completely.

I don't think you can remove (2) from qcow2 TRIM.

Why not? If the guest writes to the same logical sector, you reallocate that cluster and update L2. All you need to make sure is that the refcount table is not updated and synced until L2 has been synced (directly or as a side effect of a guest sync).

This is the key feature of qed. Because there's only one piece of metadata, you never have to worry about metadata ordering. You can amortize the cost of metadata ordering in qcow2 by batching certain operations but not all operations are easily batched.

Unless you introduce a freelist, in which case you have exactly the same problems as qcow2 (perhaps with a better on-disk data structure). If you don't introduce a freelist, you have unbounded leakage on power failure. With a freelist you can always limit the amount of leakage.


Maybe you could batch trim operations and attempt to do them all at once. But then you need to track future write requests in order to make sure you don't trim over a new write.

Yes.


When it comes to data integrity, increased complexity == increased chance of screwing up.

True.

--
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]