Re: [RFC] cache architecture

From: Henrik Nordström <henrik_at_henriknordstrom.net>
Date: Tue, 24 Jan 2012 21:27:27 +0100

tis 2012-01-24 klockan 12:21 -0700 skrev Alex Rousskov:

> We had to think that way before Rock because the intransit space and
> cache space were the same thing. I agree that we should not, ideally,
> assume that any cache (memory and/or disk) is present at any given time.
> This helps with startup, shutdown, and when dealing with disk failures.

For what it's worth cache_mem started out as transit memory which then
grew into being abused as a cache.

> The assumption is no longer there, but there is still code that uses it.
> This is one of the reasons why I consider finishing deleting store_table
> very important.

Agreed.

> Collapsables can go through disk. If disk caching is also disabled, we
> cannot collapse requests because the admin told us not to cache at all.

Technically collapsing is still possible as it's more about stream
splitting than caching. But doing it without caching would be a bit
awkward.

> If "MUST purge" is just a MAY because things will usually work even if
> the cache does not purge, then this is a question for HTTP WG because we
> would not be able to reach an agreement on this issue here; IMHO, a
> burden of proof that ignoring MUST is OK should be on those who want to
> ignore it. I do not see a point in those MUSTs if we can violate them at
> will by deploying a proxy with two out-of-sync caches.

Didn't that MUST get degraded in HTTPbis? Have unfortunately lost track
a bit of HTTPbis in the last year.

> For COSS, you may not need a DIRTY restart because, *IIRC*, Squid COSS
> does not use swap.state although it does create it.

Squid-2 COSS do not create swap.state at all I think. The defunct
Squid-3 does but that's more of an implementation artefact than actual
use I think.

Regards
Henrik
Received on Tue Jan 24 2012 - 20:27:59 MST

This archive was generated by hypermail 2.2.0 : Wed Jan 25 2012 - 12:00:11 MST