[Fwd: Squid store replacement policies]

Damn domain change ;-) Accidently sent this to squid-dev@ircache.net..

/Henrik

attached mail follows:

I am looking into breaking out the storage policies in separate modules
similar to the store I/O modules, and am starting by trying to define
the API. What I have come up with so far is:

* Create a storage policy instance where objects are maintained

   policy = createStoragePolicy("type")

  policy is cbdata registered

* Destroy a storage policy instance

   policy->free()

* Add an object to the policy

   policy->add(policy, entry)

* Remove an object from the policy out of policy order

   policy->delete(policy, entry)

* Initialize a walk of the policy database

   walker = policy->walkInit(policy);

  walker is cbdata registered

* Initialize a search for removal candidates

   walker = policy->purgeInit(policy);

  walker is cbdata registered

  The walker will remove each returned object from the policy.
  Returned objects are guaranteed to not be locked.

* Get the next object in a walk/search

   entry = walker->next(walker);

   returns NULL when there is no more objects to return

* Finish a walk/search, destroys walker.

   walker->done(walker);

* Hint to the policy that an object is/has been referenced

   policy->referenced(policy, entry)

First question is if there is any other hints a replacement policy needs
to know? (other than the object info in StoreEntry, and access
references)

I don't think LRU requires any other hints, but what about the heap
based policies, and other ideas for interesting algorithms?

Second question is if I have forgotten anything obvious (or less
obvious) in the API definition above, or added anything which does not
belong there?

Note: I do not intend to have the store policy determine when space
needs to be recaimed or how much. This is up to the storage directories
to handle. The job of the storage policy is solely to determine in which
order the objects are deleted.

/Henrik
Received on Mon Apr 24 2000 - 17:36:33 MDT