Date: Wed, 17 Mar 1999 08:29:54 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Mikhail A. Sokolov" <mishania@demos.net> Cc: Greg Lehey <grog@lemis.com>, "Mikhail A. Sokolov" <mishania@demos.net>, current@FreeBSD.ORG Subject: Re: repeated ufs_dirbad() panics on 4.0-c Message-ID: <199903171629.IAA30097@apollo.backplane.com> References: <19990316223637.A31464@demos.su> <19990317125112.T429@lemis.com> <19990317151924.B3718@demos.su>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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?
:
:--
:-mishania
It kinda sounds like you have two overlapping partitions.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199903171629.IAA30097>