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

[Avi Kivity <avi@redhat.com>]

  On 09/09/2010 08:43 PM, Anthony Liguori wrote:
>> Hm, we do have a use case for qcow2-over-lvm.  I can't say it's 
>> something I like, but a point to consider.
>
>
> We specifically are not supporting that use-case in QED today.  
> There's a good reason for it.  For cluster allocation, we achieve good 
> performance because for L2 cluster updates, we can avoid synchronous 
> metadata updates (except for L1 updates).
>

As I've mentioned several times, if you preallocate, then you amortize 
that cost of keeping track of the physical image size.

> We achieve synchronous metadata updates by leveraging the underlying 
> filesystem's metadata.  The underlying filesystems are much smarter 
> about their metadata updates.  They'll keep a journal to delay 
> synchronous updates and other fancy things.

They only guarantee that the filesystem is consistent.  A write() that 
extends a file may be reordered with the L2 write() that references the 
new cluster.  Requiring fsck on  unclean shutdown is very backwards for 
a 2010 format.

>
> If we tried to represent the disk size in the header, we would have to 
> do an fsync() on every cluster allocation.

On every N cluster allocations.

>
> I can only imagine the use case for qcow2-over-lvm is performance.  
> But the performance of QED on a file system is so much better than 
> qcow2 that you can safely just use a file system and avoid the 
> complexity of qcow2 over lvm.
>

qcow2 over lvm is typically used on clusters.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.