Re: [squid-users] endless growing swap.state after reboot

I think you should setup -CURRENT FreeBSD boxes to test gjournal[1].
Maybe gjournal can help you out, but you'll only know if you test it on
your own.

gjournal will be probably on the next FreeBSD engineering release,
7.0-RELEASE[2].

Cheers,
m0f0x

[1] http://wiki.freebsd.org//gjournal (historic)
... http://docs.freebsd.org/cgi/mid.cgi?20060619131101.GD1130
[2] http://www.freebsd.org/releases/7.0R/schedule.html

On Wed, 8 Aug 2007 07:12:37 -0300 (BRT)
"Michel Santos" <michel@lucenet.com.br> wrote:

>
> I am coming back with this issue again since it is still persistent
>
> This problem is real and easy to repeat and destroys the complete
> cache_dir content. The squid vesion is 2.6-Stable14 and certainly it
> is with all 2.6 versions I tested so far. This problem is not as easy
> to launch with 2.5 where it happens in a different way after an
> unclean shutdown.
>
> How to repeat this is easy, on any 2.6 version you shut down the
> machine with rc.shutdown time shorter than squid needs to close the
> cache_dirs what then kills the still open squid process[es] - no hard
> reset or power failure is necessary.
>
> After reboot squid gets crazy with swap.state on the affected
> cache-dirs as you can see in messages and cache_dir graphs I put
> together from two different machines in the following file
>
> Important here, the partitions ARE clean from OS's view and fsck is
> not beeing invoked and running fsck manually before mounting them
> does NOT change anything.
>
> You also can see on the machine with 4 cache_dirs that only two dirs
> are beeing destroyd, probably because of their size which needed
> longer to close them
>
> http://suporte.lucenet.com.br/supfiles/cache-prob.tar.gz
>
> This happens with 100% sure hit with AUFS and DISKD and UFS still does
> what squid-2.5 did:
>
>
> - squid-2.6 creates a never-ending-growing swap.state until the disk
> is full and the squid process dies becaus of disk full
>
> - squid-2.5 let the swap.state as is and empties the cache_dirs
> partially or completely
>
>
> Even I can see that this can be understood as unclean shutdown I must
> insist that the growing swap.state and cache_dir Store rebuild
> negative values and it's 2000%-and-what-ever values in messages are
> kind of strange and probably wrong
>
> What I do not understand here is the following.
>
> So fare I ever was told that the problem is a corrupted swap.state
> file
>
> But for my understandings the cached file is beeing referenced in
> swap.state soon it is cached.
>
> This obviously should have been happened BEFORE squid is shutting
> down or dies so why squid still needs to write to swap.state at this
> stage?
>
> And if it for any reason did not happened than the swap.state rebuild
> process detect and destroys the invalid objects in each cache_dir on
> startup
>
> If squid needs to read swap.state in order to close the cache_dirs
> than it would be enough to have swap.state open for reading? Then
> certainly it does not get corrupted or not?
>
>
> Since you tell me that *nobody* has this problem what I certainly can
> not believe ;) but seems you guys are using linux or windows then
> might this be related to freebsd's softupdate on the file system and
> squid can not handle this? Should I disable it and check it out?
>
>
> michel
> ...
Received on Wed Aug 08 2007 - 06:52:08 MDT