Re: [Qemu-devel] Re: Strategic decision: COW format

[Anthony Liguori]

On 02/22/2011 10:15 AM, Kevin Wolf wrote:
> Am 22.02.2011 16:57, schrieb Anthony Liguori:
>    
> > On 02/22/2011 02:56 AM, Kevin Wolf wrote:
> >      
> > > *sigh*
> > >
> > > It starts to get annoying, but if you really insist, I can repeat it
> > > once more: These features that you don't need (this is the correct
> > > description for what you call "misfeatures") _are_ implemented in a way
> > > that they don't impact the "normal" case.
> > >        
> > Except that they require a refcount table that adds additional metadata
> > that needs to be updated in the fast path.  I consider that impacting
> > the normal case.
> >      
> Like it or not, this requirement exists anyway, without any of your
> "misfeatures".
>
> You chose to use the dirty flag in QED in order to avoid having to flush
> metadata too often, which is an approach that any other format, even one
> using refcounts, can take as well.
>    

It's a minor detail, but flushing and the amount of metadata are 
separate points.

The dirty flag prevents metadata from being flushed to disk very often 
but the use of a refcount table adds additional metadata.

A refcount table is definitely not required even if you claim the 
requirement exists for other features.  I assume you mean to implement 
trim/discard support but instead of a refcount table, a free list would 
work just as well and would leave the metadata update out of the fast 
path (allocating writes) and instead only be in the slow path 
(trim/discard).

As a format feature, a refcount table really only makes sense if the 
refcount is required to be greater than a single bit.  There are more 
optimal data structures that can be used if the refcount of a block is 
fixed to 1-bit (like a free list) which is what the fundamental design 
difference between qcow2 and qed is.

The only use of a refcount of more than 1-bit is internal snapshots AFAICT.

Regards,

Anthony Liguori

> Kevin
>