Re: [Qemu-devel] Re: [PATCH v2 6/7] qed: Read/write support

[Anthony Liguori]

On 10/13/2010 08:50 AM, Avi Kivity wrote:
>  On 10/13/2010 03:24 PM, Anthony Liguori wrote:
> > On 10/13/2010 08:07 AM, Kevin Wolf wrote:
> > > Am 13.10.2010 14:13, schrieb Stefan Hajnoczi:
> > > > We can avoid it when a backing image is not used.  Your idea to check
> > > > for zeroes in the backing image is neat too, it may well reduce the
> > > > common case even for backing images.
> > > The additional requirement is that we're extending the file and not
> > > reusing an old cluster. (And bdrv_has_zero_init() == true, but QED
> > > doesn't work on host_devices anyway)
> >
> > Yes, that's a good point.
> >
> > BTW, I think we've decided that making it work on host_devices is not 
> > that bad.
> >
> > We can add an additional feature called QED_F_PHYSICAL_SIZE.
> >
> > This feature will add another field to the header that contains an 
> > offset immediately following the last cluster allocation.
> >
> > During a metadata scan, we can accurately recreate this field so we 
> > only need to update this field whenever we clear the header dirty bit 
> > (which means during an fsync()).
>
> If you make QED_F_PHYSICAL_SIZE an autoclear bit, you don't need the 
> header dirty bit.

Yes, autoclear bits are essentially granular header dirty bits.

Regards,

Anthony Liguori

> > That means we can maintain the physical size without introducing 
> > additional fsync()s in the allocation path.  Since we're already 
> > writing out the header anyway, the write operation is basically free 
> > too.
>
> I don't see how it is free.  It's an extra write.  The good news is 
> that it's very easy to amortize.