On Wed, Oct 13, 2010 at 04:10:25PM +0200, Avi Kivity wrote: > On 10/13/2010 04:07 PM, Stefan Hajnoczi wrote: > >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. > > I thought you'd only use a header size field when you don't have a > real file size. Why do you need both?
I probably didn't understand correctly :). You said with QED_F_PHYSICAL_SIZE autoclear you don't need the header dirty bit. I don't see how it eliminates the need for the header dirty bit. Stefan
