[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squid-users
Subject:    Re: [squid-users] R: squid stores multiple copies of identical ETags
From:       Alex Rousskov <rousskov () measurement-factory ! com>
Date:       2020-06-30 14:16:20
Message-ID: e7a7380a-332e-4a5f-b14e-2771b147c1a3 () measurement-factory ! com
[Download RAW message or body]

On 6/30/20 5:10 AM, Tabacchiera, Stefano wrote:

> So I'm assuming that only one object on disk (the last one retrieved) is
> the object referenced as "active" by squid, all the rest being trashable.
> 
> Since the client is forcing a "no-cache" header, squid does what the
> client is asking for, and every time it stores the object on disk.
> 
> I'm also assuming that IF another client asked the same object without
> the "no-cache" header, squid would serve the latest cached object on disk.
> 
> If I'm right so far, squid never "overwrites" the old copy of an object
> on disk. Instead, it stores a new one, marking it as "active", 

Yes, the above matches my understanding (for some definition of "last
one", "overwrites", and "active"). The actual situation is a bit more
nuanced (e.g., Squid could be storing and using multiple copies of the
same resource concurrently, even though any new request will never see
more than one copy), but those low-level details may not matter to your
investigation.


> and let the deletion task to (a)ufs threads.

I cannot confirm or deny this part -- I do not know whether garbage
collection is delegated to aufs thread(s) -- but it sounds plausible.


HTH,

Alex.
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[prev in list] [next in list] [prev in thread] [next in thread]