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: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format
Date: Fri, 10 Sep 2010 12:33:09 +0100

On Fri, Sep 10, 2010 at 12:25 PM, Avi Kivity <address@hidden> wrote:
>  On 09/10/2010 02:14 PM, Avi Kivity wrote:
>>
>>>
>>> qcow2 is not a properly designed image format.  It was a weekend hacking
>>> session from Fabrice that he dropped in the code base and never really
>>> finished doing what he originally intended.  The improvements that have been
>>> made to it are almost at the heroic level but we're only hurting our users
>>> by not moving on to something better.
>>>
>>
>> I don't like qcow2 either.  But from a performance perspective, it can be
>> made equivalent to qed with some effort.  It is worthwhile to expend that
>> effort rather than push the burden to users.
>
> btw, despite being not properly designed, qcow2 is able to support TRIM.
>  qed isn't able to, except by leaking clusters on shutdown.  TRIM support is
> required unless you're okay with the image growing until it is no longer
> sparse (the lack of TRIM support in guests make sparse image formats
> somewhat of a joke, but nobody seems to notice).

Anthony has started writing up notes on trim for qed:
http://wiki.qemu.org/Features/QED/Trim

I need to look at the actual ATA and SCSI specs for how this will
work.  The issue I am concerned with is sub-cluster trim operations.
If the trim region is less than a cluster, then both qed and qcow2
don't really have a way to handle it.  Perhaps we could punch a hole
in the file, given a userspace interface to do this, but that isn't
ideal because we're losing sparseness again.

Stefan



reply via email to

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