Re: [squid-users] hier_code acl and cache allow/deny

On 02/21/2014 06:29 AM, Nikolai Gorchilov wrote:
> On Fri, Feb 21, 2014 at 7:34 AM, Alex Rousskov wrote:
>> With aufs, kid2 does not know that kid1 already has the object in its
>> kid1-specific cache_dir because aufs store is not SMP-aware: You are
>> forced to use kid-specific aufs cache_dirs to avoid cache corruption.

> Unfortunately yes :)

>> Besides making aufs SMP-aware, it would be possible to reduce such
>> duplicate storage by hacking the shared memory cache index to keep
>> information about the cache_dir holding the object (if any), but it is
>> not easy to do, it will not work reliably, and you will still face
>> similar problems when the object is purged from the memory cache or is
>> never stored there.

> Seems switching shared_memory to off is the only "stable" solution for now.

I am not sure which problem you are trying to solve by switching the
shared memory cache off, but doing so will not decrease the amount of
duplication in kid-specific caches. In fact, it will _add_ memory cache
duplication to the existing disk cache duplication.

Said that, I personally have not analyzed how a shared memory cache
interacts with non-SMP stores. It is possible that the two are not
compatible in some ways. I have not heard of any such incompatibilities
yet, but disabling the shared memory cache will bring you closer to a
well-understood and supported (albeit inefficient) SMP configuration.

> Moving to large rock is also an option, but I'm afraid to do so due to
> the heavy trunk refactoring nowadays. How feasible is back-porting
> only the bare minimum for large rock support from trunk to 3.4 in your
> opinion?

Large rock support required significant changes to the core Store API.
It would be impossible to backport Large Rock without backporting those
changes as well. It will be a significant effort, expanding well beyond
adding a new storage module (or updating an old one).

FWIW, I do not recommend starting such a project, especially without
getting a Squid Project approval on v3.4 inclusion of the results first.
I am not sure I would support such an approval personally (but I would
probably not block it either).

IMHO, if you need Large Rock, the best way forward is to make
trunk-based code stable enough for your deployment needs. Yes, there
will be some pains along the way, but that approach may require smaller
overall effort with larger overall payoff than porting Large Rock back
to v3.4.

Do keep in mind that v3.4 did not quite work for you either! In my
experience, virtually any new deployment in a demanding environment
and/or with an admin that looks for suboptimal behavior is likely to
require some fixes/workarounds/improvements. Thus, if you are willing to
do the dance and want cutting-edge features, backporting is often an
inferior solution, especially when it comes to large features affecting
Squid core.

$0.02,

Alex.
Received on Fri Feb 21 2014 - 15:44:13 MST