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

[Avi Kivity <avi@redhat.com>]

  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.