>> I mean: squid would store a new copy of the object while leaving the
>> old copy deletion to cleanup task?
>Some parts of the cleanup process may be delegated. The details depend on the
>cache_dir type. I do not know or remember aufs specifics, but I suspect that
>all ufs-based cache_dirs,
Alex,
first of all, thank you for your clarification.
>Squid does not know that the response headers and body have not changed.
>Squid could, in theory, trust the URL+Vary+ETag+etc. combination as a
>precise response identity, but it is a bit risky to do that by default
>because ET
>>>In general, if the same object occuring N times on disk is a problem,
>>>you have issues with misconfigured cache_dir parameters. eg the
>>> cache_dir size is too big for the physical disk it is stored on.>
>> That's the point. There's a LOT of identical objects on disk.
>> I have 2x100g
>In general, if the same object occuring N times on disk is a problem,
That's the point. There's a LOT of identical objects on disk.
>you have issues with misconfigured cache_dir parameters. eg the
cache_dir size is too big for the physical disk it is stored on.
I have 2x100gb dedicated disk
Hello there,
I have the following issue with squid (squid-3.5.20-12.el7_6.1.x86_64 on RHEL
7.6)
A client requests a json with "no-cache" header via proxy.
Squid forwards the request to origin server, which replies with "ETag" header
(object is cachable).
Squid stores the object in cache_dir and
