From owner-freebsd-hackers Sat Feb 20 14:11:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id CBC611199A for ; Sat, 20 Feb 1999 14:11:02 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id OAA32309; Sat, 20 Feb 1999 14:10:46 -0800 Date: Sat, 20 Feb 1999 14:10:45 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Doug Rabson Cc: freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message