Re: Direct mapped like caching

Alex Rousskov wrote:

> I suspect that it is impossible to select the best approach at
> this point. There are two many unknowns. Moreover, it is likely, IMO,
> that there is no "best" approach at all; many approaches are the
> "best" depending on the environment.

I fully agree, and I am certain that new problems will be found on the
way. Both in design, implementation and heritage..

> The only big problem that I see is keeping old and new schemes
> supported by the same Squid "core". It seems to me that a lot of
> changes will be required to enable Squid to support StoreEntry-based
> and StoreEntry-less approaches along with all the different modules
> for file systems and such. At some point, it may be not worth it to
> try to support all models/modules that ever existed or have been
> proposed.

A lot of changes is required to support StoreEntry less operation as a
integrap part of the design. Some of the changes has already seen the
light in the modio approach, and a lot more is planned.

Today the policy indexes are separated from the core, and the next
logical step is to move the store index the same way, possibly allowing
the two to merge again.

The next, and much bigger change is to change Squid to be request
centric rather than StoreEntry centric, and then have a API defined
where the object stores (cache_dir) is queried in an efficient manner.
So we are most likely talking Squid-3.0 before this sees the light in
the desgn.

My goal is to have an infrastructure that supports objects stores with
* in-core indexes
* without in-core indexes
* synronous operation
* asyncronous operation
* any indexing sheme.

In short my immediate plan is to move all things related to indexing out
of the core, and instead have the core concentrate on request
forwarding.

But as seen, far more fundamental design changes are required for a well
designed StoreEntry-less operation, but separating the store index is at
least a first step that would allow one to start experimenting with such
stores in a reasonably structured manner.

/Henrik
Received on Mon Nov 06 2000 - 16:08:50 MST