Date: Sat, 20 Feb 1999 23:02:53 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Matthew Jacob <mjacob@feral.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday - update Message-ID: <Pine.BSF.4.05.9902202300460.82049-100000@herring.nlsystems.com> In-Reply-To: <Pine.LNX.4.04.9902201351410.31494-100000@feral-gw>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 20 Feb 1999, Matthew Jacob wrote: > > > On Sat, 20 Feb 1999, Matthew Jacob wrote: > > > > > > > > As of the last set of fixes that added some more splbio protection, the > > > testing has gone a lot better. Many thanks. Now I'll start raising the bar > > > from 9GB filesystems to > 100GB filesystems with larger blocksizes (unless > > > someone says "No! No! Don't do that!") > > > > Its good that your panic seems to have been addressed but I can't see any > > quick solutions for the responsiveness problem. It appears to be a > > combination of the way that BSD looks up pathnames and the lack of any > > mechanism from stopping writer processes from monopolising the i/o queues. > > yes, I saw the mail. fixing the panic is the first step. > > I'm not entirely sure that the root inode lock is the whole problem. I > think another problem may be just growing very large delayed write queues- > there doesn't seem to be any way any more to keep a single process from > blowing the whole buffer cache- but I'd be the first to admit that my > knowledge of this area of unix internals is 7-10 years old. Certainly the root inode lock is the symptom. Even if it was fixed (by rewriting lookup), a single process can still generate unreasonable amounts of i/o. With a merged vmio system, this can cause huge latencies as we have seen. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9902202300460.82049-100000>