On Apr 22, 2009, at 4:56 AM, Amos Jeffries wrote:
> Chris Woodfield wrote:
>> So I'm running with COSS under 2.7STABLE6, we've noticed (as I can
>> see others have, teh Googles tell me so) that the COSS rebuild a.
>> happens every time squid is restarted, and b. takes quite a while
>> if the COSS stripes are large. However, I've noticed that while the
>> stripes are being rebuilt, squid still listens for and handles
>> requests - it just SO_FAILs on every object that would normally get
>> saved to a COSS stripe. So much for that hit ratio.
>> SO - the questions are:
>> 1. Is there *any* way to prevent the COSS rebuild if squid is
>> terminated normally?
>
> The indexes are stored in swap.state. Check that it is being done
> properly by your Squid.
>
This could be the issue - when I exit squid, I notice that my
$coss_file.dat and $coss_file.dat.last-clean files all have zero size.
Any idea why this might be happening?
The relevant section of our squid.conf reads as follows:
cache_dir aufs /usr/squidcache.0/cache/ 750000 16 256 min-size=1000000
cache_dir coss /usr/squidcache.0/cache/coss1.dat 30000 block-size=4096
max-size=1000000 membufs=100
cache_dir coss /usr/squidcache.0/cache/coss2.dat 30000 block-size=4096
max-size=1000000 membufs=100
cache_dir coss /usr/squidcache.0/cache/coss3.dat 30000 block-size=4096
max-size=1000000 membufs=100
cache_swap_log /usr/squidcache.0/cache/%s
Thanks,
-C
>> 2. Is there a way to prevent squid from handling requests until the
>> COSS stripe is fully rebuilt (this is obviously not good if you
>> don't have redundant squids, but that's not a problem for us) ?
>
> I believe its possible. If its not a local failure to find
> swap.state for the COSS dir then it will be a code fix.
> Unfortunately we developers are no longer actively working on
> Squid-2 without a paid support contract. Also Adrian our storage
> expert who would be the best to ask has retired from active
> alterations.
>
> Amos
> --
> Please be using
> Current Stable Squid 2.7.STABLE6 or 3.0.STABLE14
> Current Beta Squid 3.1.0.7
>
Received on Wed Apr 22 2009 - 13:51:30 MDT
This archive was generated by hypermail 2.2.0 : Wed Apr 22 2009 - 12:00:02 MDT