>> Hi,
>>
>>Yesterday i noticed during a routine check of the system a lot of activity
>>of Squid. A little investigation showed that one disk had become full en
>>Squid couldn't write his files there anymore. Squid solution seemed to
>>be rm -rf /cache.
>>
>> Hmm..i'm not that happy with that. Squid didn't seem to stop at the low
>> level marks, but continued erasing everything. Stopping squid and
>> restarting Squid maked it go fill the cache again.
>>
>> Is this supposed behavior ? I hope not.
>>
>I have also seen this behaviour, in our case it was with squid 1.1.9 on a
>Linux 2.0.29 PC.
>
>We have the high & low watermarks set to the same value in the hope that
>squid will delete objects as it needs the space rather than loading the
>machine heavily while it deletes a few hundred meg every few days. Is
>this likely to cause such a problem to occur?
The same happened to us few days ago. We lost nearly 60% of our precious
cache, but I think it's unlikely that "autodeleting bug" is caused by
equal "high & low watermarks". ( our settings are 90 & 95 % )
I suspect rather fragment of code handling rewriting "log" file(s).
Why ? It's our story in short:
1. Filesystem became nearly full. ( It wasn't squid's fault, some other
process made it.)
2. While restarting system, squid couldn't succesfully rewrite logs
leaving "uncomplete" log file.
3. While next restarting, squid flushed all cached objects it couldn't
find in "new" "uncomplete" log file ( I suppose )
Because it was our fault we let the other process fill squid's
partition by mistake, I don't blame squid for it. But maybe code rewiting
log files should carefully check free space while all stages of
rewriting log files, because as you see, checking only high watermark
could not be enough in all cases... :-(
Tomek
Received on Wed Jun 04 1997 - 03:48:08 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:35:22 MST