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

[Anthony Liguori <anthony@codemonkey.ws>]

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?

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.

Regards,

Anthony Liguori