[Top][All Lists]

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

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format
Date: Fri, 10 Sep 2010 08:39:21 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6

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

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?

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. Unclean mounts require an fsck() and both qcow2 and qed require it.

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.

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.

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.

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


Anthony Liguori

reply via email to

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