Re: ENTRY_SPECIAL => content pinning?

From: Henrik Nordstrom <hno@dont-contact.us>
Date: Mon, 27 May 2002 10:48:41 +0200

Joe Cooper wrote:

> Right. The icons that Squid uses for FTP directory listings, etc. are
> loaded at startup, and I suppose they live in memory for the life of the
> process. It wouldn't make sense for them to swap out to disk, since we
> already have local copies of them.

Eventually the memory pinning will be replaced by a "from files" store
type, making Squid act a bit more like a normal web server, but until
such a store has been done, memory pinning of the icons is the simplest
and most suitable way of dealing with them..

Keep in mind that there may be no cache_dir store into where the icons
or other internal objects can be swapped out..

> Does pinning imply we should be controlling how long an item is fresh?
> I was thinking of pinning merely in terms of "These items, marked
> PINNED, are priority items, and should not be removed from the cache
> object store until they expire (expiry being set via normal mechanisms)."

I think what you are really after is a more customizable removal policy,
not simple pinning of objects.

> I think all a cache_pinned directive needs to do is decide what
> gets pinned (and no matter how infrequently it is used, we keep it on
> disk). Right? Or do you have other uses in mind?

If pinning is done, it should not do more.. however, pinning presents
the interesting topic on what do do if you pin more data than there is
space? My answer today is "don't do that".

Personanlly I would prefer better controlled removal policies. The only
problem in writing a policy that does exacly what one wants is that
there is no room for policy specific information in swap.state,
presenting a bit of a problem for more advanced policies on cache
rebuild..

> The concept of cache pinning is quite new to me, so I won't pretend to
> know all of the uses for it or how it 'ought' to work.

I don't think there is a 'standard' way it 'ought' to work.

Regards
Henrik
Received on Mon May 27 2002 - 03:36:46 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:15:30 MST