Re: [Qemu-block] [PATCH 2/3] qcow2: add option to clean unused cache entries after some time

[Max Reitz]

On 28.05.2015 17:13, Eric Blake wrote:
> On 05/28/2015 08:56 AM, Max Reitz wrote:
> > On 27.05.2015 11:46, Alberto Garcia wrote:
> > > This adds a new 'cache-clean-interval' option that cleans all qcow2
> > > cache entries that haven't been used in a certain interval, given in
> > > seconds.
> > >
> > > This allows setting a large L2 cache size so it can handle scenarios
> > > with lots of I/O and at the same time use little memory during periods
> > > of inactivity.
> > >
> > > This feature currently relies on MADV_DONTNEED to free that memory, so
> > > it is not useful in systems that don't follow that behavior.
> > >
> > > +++ b/qapi/block-core.json
> > > @@ -41,6 +41,10 @@
> > >    # @corrupt: #optional true if the image has been marked corrupt;
> > > only valid for
> > >    #           compat >= 1.1 (since 2.2)
> > >    #
> > > +# @cache-clean-interval: interval in seconds after which unused L2 and
> > > +#                        refcount cache entries are removed. If 0 then
> > > +#                        this feature is not enabled (since 2.4)
> > > +#
> > >    # @refcount-bits: width of a refcount entry in bits (since 2.3)
> > >    #
> > >    # Since: 1.7
> > > @@ -50,7 +54,8 @@
> > >          'compat': 'str',
> > >          '*lazy-refcounts': 'bool',
> > >          '*corrupt': 'bool',
> > > -      'refcount-bits': 'int'
> > > +      'refcount-bits': 'int',
> > > +      'cache-clean-interval': 'int'
> > >      } }
> > I'm not too happy about making this part of ImageInfoSpecificQCow2. Two
> > reasons for this: First, it's eventually part of ImageInfo, which is
> > defined as "Information about a QEMU image file", but this option cannot
> > be set in the image file itself but is only a run-time option.
> >
> > Second, my original goal for ImageInfoSpecific was to provide more
> > information through qemu-img info, and this value will look pretty
> > strange there.
> >
> > I don't know how to resolve this quandary, though. Since qemu cannot
> > change this interval by itself, I think not providing an interface for
> > reading it is fine. On the other hand, if Eric finds such an interface
> > absolutely mandatory, I can't think of a better place to return it than
> > here.
> Can we mark the parameter optional, and only provide it when it is
> non-zero?  That way, qemu-img (which cannot set an interval) will not
> report it, and the only time it will appear is if it was set as part of
> opening the block device under qemu.

That sounds good.

Max

> > The only solution which would satisfy both requirements would be another
> > structure which contains "online" flags, and thus is not evaluated by
> > qemu-img info, but only by QMP commands. But that's ugly.
> Yeah, I'm not sure such duplication helps.  I'd still like it reported
> somewhere, though, as it is nice to query that a requested setting is
> actually working.