On Wed, Oct 13, 2010 at 03:50:00PM +0200, 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.
Do you mean we just need to check the physical size header field against
the actual file size? If the two are different, then a consistency
check is forced.
> >
> >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.
We only need to update the header field on disk when we're already
updating the header, so it's not even an extra write operation.