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@xxxxxxxxxxxxxx> 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 > ...
