On 26.01.2012 12:02, RW wrote:
I noticed today that according to "squidclient mgr:storedir" my
retention had dropped from 200+ days to 5 days, but all the content
still seemed to be there. I tried rebuilding swap.state from the
cache
files, but it made no difference.
Under the LRU retention policy the cache age is just a measure of the
oldest file creation timestamp. Not the number of files nor an average.
I suspect you had one file up at 200 days and most of the cache under 5
days. That file recently being erased the retention details drop
immediately to a different oldest entry (added 5 days ago).
I'm guessing that the rebuild had already been done automatically and
that when that happens there's no explicit sort to restore lru order,
it just relies on subsequent access and ageing. Does that sound
reasonable?
I was wondering, if I wrote bit of script to rename the cache files
into mtime order could I rebuild swap.state in lru order?
You could, but it would be of little value. The cache file names and
swap.state order has no bearing on the memory index hash algorithm,
retention policy algorithm, or live traffic cache-control headers being
received by Squid from outside.
FYI: swap.state is simply a journal of what has been added/removed from
that cache. A "rebuild' is just a dump of the memory index contents into
a fresh empty journal file. Effectively erasing all records of things
removed.
NP: we do need help assembling a tool which can scan the cache and
rebuild swap.state offline. Doing a DIRTY cache scan without affecting
Squid traffic operations. If you want to take that up I can point you at
the bits and pieces you need to know for the task and mentor the audit.
Amos
