Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 Mar 1999 15:19:25 +0300
From:      "Mikhail A. Sokolov" <mishania@demos.net>
To:        Greg Lehey <grog@lemis.com>
Cc:        "Mikhail A. Sokolov" <mishania@demos.net>, current@FreeBSD.ORG
Subject:   Re: repeated ufs_dirbad() panics on 4.0-c
Message-ID:  <19990317151924.B3718@demos.su>
In-Reply-To: <19990317125112.T429@lemis.com>; from Greg Lehey <grog@lemis.com> on Wed, Mar 17, 1999 at 12:51:12PM %2B1030
References:  <19990316223637.A31464@demos.su> <19990317125112.T429@lemis.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990317151924.B3718>