On Fri, Sep 10, 2010 at 12:25 PM, Avi Kivity <a...@redhat.com> 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