On Wed, Mar 17, 1999 at 12:51:12PM +1030, Greg Lehey wrote: # On Tuesday, 16 March 1999 at 22:36:38 +0300, Mikhail A. Sokolov wrote: # > Hello, # > # > we're experiencing repeated 4.0-C (as of today, something around 12:00 # > GMT, 1999-03-16) ufs_dirbad() panics, which are the # > following (below), which usually occur when squid is running. The box # > doesn't have ccd, nor vinum nor anything fancy in it's config, no SMP either. # > Squid's spool is hardware (IFT3102) RAID1, 2x9gb (i.e. 4 disks): # > /var/crash# gdb -k kernel.1 vmcore.1 # > IdlePTD 2682880 # > initial pcb at 21c7b8 # > panicstr: ufs_dirbad: bad dir # > panic messages: # > --- # > panic: ufs_dirbad: bad dir # # Have you looked at the directory? Theoretically this could be a # really mangled directory structure.
Yes, of course. Those swap catalogues which are not to be touched by squid are turned into it's swapfiles, sometimes there's an error of 'bad file descriptor' and such. As I said in reply to Julian, I've newfs'ed these spools plenty times, - errors are repeated and, besides, lookalike. That's a glitch in FFS somewhere, I assume: I've had similiar panics on another squid with exactly the very same hardware/software configuration, besides the fact the OS there was 3.[01]-S. Similiar panics, different scsi disks, tryed not to use the mentioned IFT RAID - no difference. I.e. I could've agreed with that this could be really doomed directory, but no, it's not that way, squid's allocating objects in memory, when it reaches the limit it'd swap it to the spool (as per LRU and such rules) and then, after it dies, I find that ~1 recursive swap file (2 disksx9gb, 256 catalogues of 16 subdirs each in 8 and 6 cache_dirs as applicable to two spools) in each of the subdirs (second level cache) has died, - has been automagically converted to contain some crap [by FFS?]. What could help is that squid is configured to use poll(), doesn't use threads, doesn't do async (i.e. as squid undestands it, it's an option there) operations. Mounts on the FS's are noatime, but that ain't is the culprit, ain't they? # Greg # -- # See complete headers for address, home page and phone numbers # finger g...@lemis.com for PGP public key -- -mishania To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
