Re: Squid store replacement policies

Sorry, more interface ramble:

    0a. prog-guide-8.html#ss8.4 talks about "storage policy", which
       seems to be a very broad/vague term; it would be better to
       define what exactly that policy is, so people do not try to
       use it for something it is not designed for. An informal
       explanation of the unfortunate "storage policy" term is
       probably not good enough.

    0b. If "Policy" type is for a replacement policy, it should be
       called "RepltPolicy" or some-such. Other policies may be
       admission policy (what to cache), dataplacement policy (where
       to cache) and, perhaps, peer selection policy, etc.

    0c. The replacement policy interface is actually not designed to
       replace anything, it is designed to remove only. Thus, it is
       more appropriate to call it a removal policy

    1. It seems appropriate for some policies to benefit from
       information about the [incoming] object that is causing us to
       look for victims. A "purgeInit(Entry *reason)" interface
       should replace "purgeInit()". "Reason" can be null, of
       course.

    2. All walkers should be able to return a constant pointer to
       the policy that created them. The pointer must not be cached
       though because a policy may disappear at virtually any time.
       The pointer should be constant because we cannot modify the
       policy while we iterate it (based on the current API).

    3. I do not understand why a [removal] policy is creating
       "index" walkers. What does the removal policy have to do with
       iterating the cache?

       It seems to me that file system type (or whoever maintains an
       index of cached entries) should be responsible for that.

       A "Cache" type (or whoever manages all file systems) may also
       return an iterator that is capable of iterating through all
       file systems. Both per-fs iterators and "global" iterators
       are useful.

    4. What is the relation of the policy and file system? Who
       creates policies and how do they interact with the storage
       index?

    4a API says ``storage directory or memory creates a policy of
       choice for maintaining it's objects.''

       What is "memory" in the description above?

       Why storage directory must create a policy of choice? I
       would think that a fs (storage directory) can be asked to
       create a removal policy OR can be asked to use a policy
       preferred by the user. A directory can refuse in at most one
       of the above cases, of course.

       For example, a Unix FS can work with [at least] FIFO or LRU
       removal policies, but may "prefer" a GDSZ policy or whatever.
    
       If storage directory creates a policy of choice, there should
       be no global "createPolicy(type)" interface because that
       storage directory would know how to create a policy of a
       given type (also see (5) below).

    4b The presence of the "createPolicy(type)" call implies that
       there is one policy instance for all active file systems. Is
       that intentional/desired?

       A more flexible design would be to have a per-fs removal
       policy and a global removal policy which chooses which fs
       should give up an object.

       A single global removal policy will work, but may be costly
       to implement because data from a fs index would have to be
       copied to that global policy structures, increasing memory
       requirements and possibilities for mis-communication bugs.

    5. The "createPolicy(type)" method seems like a global function
       that must know how to create policies of every possible type.
       Such a function cannot be a part of the policy API: a given
       policy should have no clue how other policies are created.

       Constructors for each policy types are likely to have
       additional parameters and configuration options. The API must
       just require that policy of type T implements a
       "createTPolicy(...)" public constructor, with parameter list
       to be specified by that particular policy.

       Moreover, I doubt "createPolicy(type)" will survive for long
       because people would want to supply configuration parameters
       for particular policies via squid.conf. Something like
        createPolicy(PolicyCfg *cfg)
       may survive longer.

    6. Is it prudent to plan for removal policies that remove more
       than one object at a time? Clustering removal operations can
       be a significant optimization for some file systems...
       Current interface makes it impossible to remove two objects
       at once when removing the first object is sufficient from
       space requirements point of view.

Thanks,

Alex.
Received on Wed Apr 26 2000 - 09:47:45 MDT