Re: [squid-users] [wishlist] removal policy should also move objects to sibling caches

From: Bob Arctor <curious@dont-contact.us>
Date: Fri, 4 Jul 2003 19:01:42 +0200

it is just approach to move objects from small-memory -fast caches, to big
-disk based - caches (slow).

big caches will almost always have some space, to handle 'homeless' requests
..

one of approaches could be sending request for file which is going to be
removed to 'big' cache, respond 'i have it' and delete it after

this would introduce allow_delayed_removal option
big caches can have this completely off

On Friday 04 July 2003 13:59, Robert Collins wrote:
> On Fri, 2003-07-04 at 06:25, Bob Arctor wrote:
> > it would be great if squids could move data to sibling caches having
> > enough free space available instead of merely deleting them.
> > this can be done by introducing special icp_balance query .
>
> ICP is one approach. Another would be to provide a generic pre-purge
> action, able to use external logic to do whatever is needed.
>
> Extending ICP may not be the best approach:
> You'll need some handshaking:
> * you can't purge a candidate until the peers have had time to pick it
> up.
> * peers may not *want* it.
>
> ICP today is very simple - you will be increasing it's complexity.
>
> That said, I'm not convinced that you need this. caches tend to be more
> rather than less full, and content being ejected is that matching your
> replacement policy - which is likely to be the same on peers, meaning
> that those objects will be immediate candidates for ejection (assuming
> you preserve metadata, which would make sense within a cluster).
>
> Rob

-- 
-- 
Received on Fri Jul 04 2003 - 11:00:19 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:17:50 MST