Re: Squid store replacement policies

Alex Rousskov wrote:

> If the policy is replaced or cannot read its metadata for some other
> reason, the policy metadata is restored by cache_dir using add() method.

Ok. I agree with you in principle, but yet I select to do incremental
development rather than try to do everything at once.

It will probably eventually look like what you have proposed, but not in
the first release I am working on now. Doing all what you propose is a
way to large step to take in one step, and what I am doing is a step in
the right direction. The major difference beteen what I am doing now and
your ideas is the policy load/store procedure, and it is only a minor
part of it. Changing this at a later time when this first level of
abstraction works properly is only yet another small incremental step,
and can even be done without breaking source compability with the
existing policies. In the first release policy load/store simply piggy
backs on the cache_dir index load and is the driving force in toe
cache_dir clean index storing. Yes, not 100% pure, but in my opinion
acceptable.

Other things which needs to be done before doing the "larger" step in a
good manner:

* A more appropriate way of handling the persistent indexes and
"transaction" logs of the disk store AND policy needs to be found. The
policy should be able to rebuild to a reasonable state even if there
wasn't a clean shutdown.

* Another method of accessing the icons than storing them in the disk
cache should be found.

* An FS interface where the policy can store/load it's meta data must be
designed.

* A relevant key for cache_dir object lookup from the policy metadata
must be found. Will probably be MD5 hash (filenumber isn't indexed and a
bit hard to lookup).

Relevant to this, but not currently needed from a API point of view is
that the "hot object cache" and "in transit data" should be re-designed
and possibly separated from each other. However, I have found a
acceptable level of encapsulation of the removal policy index from the
"disk store" and "hot object cache" by introducing the concept of a node
in the removal policy API, thus allowing the policy API to maintain
multiple independent indexes/policies for one StoreEntry.

/Henrik
Received on Sat Apr 29 2000 - 14:35:00 MDT