Search squid archive

Re: caching behavior during COSS rebuild

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



...and sure enough, it's right there in -h output...

cache$ /usr/local/squid/sbin/squid -h
	...
       -F        Don't serve any requests until store is rebuilt.
	...

/me goes to write "I will RTFM Before Posting To squid-users" 100 times on the whiteboard... :)

-C

On Apr 22, 2009, at 9:56 AM, Adrian Chadd wrote:

Well, I killed the swaplog writing entirely in Lusca - the COSS
rebuild code doesn't read from it (it was broken for various reasons
revolving mostly around code bitrot IIRC.)

There's a flag you can pass Squid to not handle requests until the
store is rebuilt - its the "-F" flag.

I'm fixing the store rebuild times in Lusca-HEAD at the moment and
this includes writing some new COSS rebuild-from-index, rebuild-from- log
and rebuild-from-rawdevice tools.



Adrian


On Wed, Apr 22, 2009, Chris Woodfield wrote:

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


--
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -



[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux