file-system corruption with recent squids

I had a little squid which had been stable running 1.1.5 (or similar)
for a long time on a little Linux machine. I decided to upgrade to
1.NOVM.x as I was about to add more disk and the memory leaks in
1.1.5 were getting to me. In any case the disk adding failed and
I've still not resolved that problem, but back in the old config
1.NOVM.21+retry was running and then the fs with the cache (and not
much else) got corrupt, with the directories of the cache being invalid.

I thought that maybe this kernel problem was triggered by somethign new
in 21, so tried 1.NOVM.20+retry which is reputed to be very stable, but
the fs got corrupted a couple of weeks later. Now this machine was
running a really old kernel (2.0.30) so I upgraded to a nice shiney one
(2.0.34pre9 for reasons I don't want to go into), and all was well for
about a day and then it hit again.

I was watching the machine this time, and spotted it shortly after the
first directory got corrupt. I fcsk'd it and then deleted the cache
and ran squid -z again to re-make the directory. I'm now waiting for
it to happen again. Is this somethign that others have seen? am I just
very unlucky or is this a known kernel problem which squid is tickling?

With 2.0.34pre9 the kernel logged the following messages each time squid
tried to access the duff directory:

Apr 20 14:29:06 edsac kernel: EXT2-fs error (device 03:04): ext2_find_entry: bad entry in directory #116756: inode out of bounds - offset=0, inode=4342253, rec_len=1024, name_len=0

[ I'm Cc:ing this to Alan Cox in case this is somethign he wants to know
about before 2.0.34 is released ]
Received on Mon Apr 20 1998 - 08:04:18 MDT