From owner-freebsd-current Wed Mar 17 4:20: 0 1999 Delivered-To: freebsd-current@freebsd.org Received: from skraldespand.demos.su (skraldespand.demos.su [194.87.5.19]) by hub.freebsd.org (Postfix) with ESMTP id DE24514C46 for ; Wed, 17 Mar 1999 04:19:55 -0800 (PST) (envelope-from mishania@skraldespand.demos.su) Received: (from mishania@localhost) by skraldespand.demos.su (8.9.3/8.9.2) id PAA03974; Wed, 17 Mar 1999 15:19:25 +0300 (MSK) (envelope-from mishania) Date: Wed, 17 Mar 1999 15:19:25 +0300 From: "Mikhail A. Sokolov" To: Greg Lehey Cc: "Mikhail A. Sokolov" , current@FreeBSD.ORG Subject: Re: repeated ufs_dirbad() panics on 4.0-c Message-ID: <19990317151924.B3718@demos.su> References: <19990316223637.A31464@demos.su> <19990317125112.T429@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <19990317125112.T429@lemis.com>; from Greg Lehey on Wed, Mar 17, 1999 at 12:51:12PM +1030 X-Useless-Header: Look ma! It's a # sign! X-Point-of-View: Gravity is myth, - the earth sucks. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 grog@lemis.com for PGP public key -- -mishania To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message