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

[Avi Kivity]

 On 09/08/2010 06:07 PM, Stefan Hajnoczi wrote:
> > >      uint32_t table_size;          /* table size, in clusters */
> > Presumably L1 table size?  Or any table size?
> >
> > Hm.  It would be nicer not to require contiguous sectors anywhere.  How
> > about a variable- or fixed-height tree?
> Both extents and fancier trees don't fit the philosophy, which is to
> keep things straightforward and fast by doing less.  With extents and
> trees you've got something that looks much more like a full-blown
> filesystem.  Is there an essential feature or characteristic that QED
> cannot provide in its current design?

Not using extents mean that random workloads on very large disks will 
continuously need to page in L2s (which are quite large, 256KB is large 
enough that you need to account for read time, not just seek time).  
Keeping it to two levels means that the image size is limited, not very 
good for an image format designed in 2010.

> > Is the physical image size always derived from the host file metadata?  Is
> > this always safe?
> In my email summarizing crash scenarios and recovery we cover the
> bases and I think it is safe to rely on file size as physical image
> size.  The drawback is that you need a host filesystem and cannot
> directly use a bare block device.  I think that is acceptable for a
> sparse format, otherwise we'd be using raw.

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.

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