From owner-freebsd-hackers Thu Feb 25 2: 8:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 039BD14BEA for ; Thu, 25 Feb 1999 02:08:52 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id KAA68421; Thu, 25 Feb 1999 10:08:18 GMT (envelope-from dfr@nlsystems.com) Date: Thu, 25 Feb 1999 10:08:18 +0000 (GMT) From: Doug Rabson To: Matthew Dillon Cc: Luoqi Chen , freebsd-hackers@freebsd.org, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update In-Reply-To: <199902250916.BAA02250@apollo.backplane.com> 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 Thu, 25 Feb 1999, Matthew Dillon wrote: > Oof! Well, that takes the cake. I just had a supervisor stack overflow > due to the writerecursion junk in getnewbuf(). 5 levels of > (FFS + VN + NFS-FILE) resulted in 60+ subroutine levels in DDB's traceback. > That is after DDB faulted on itself with just me hitting return. > > Doh. > > I think I have a solution. > > Normally, B_DELWRI buffers are pushed out by the syncer. Normally > getnewbuf() never needs to deal with B_DELWRI buffers. It is only > during heavy buffered write I/O where the dirty buffers trash the > buffer queues. > > At the moment, getnewbuf() attempts to convert B_DELWRI buffers into > async writes in order to push them out. This is what leads to the > recursion problem. I don't think we can afford to recurse even once, > therefore we cannot push out B_DELWRI buffers in getnewbuf(). At all. > > I think the proper solution is to speed up the syncer when getnewbuf() > gets starved. > > I also see a fairly serious potential low-free-buffer lockup. At the > moment, getblk() ( which calls getnewbuf() ) treats the lo buffer limit > as 'lofreebuffers' and blocks if numfreebuffers < lofreebuffers. I > believe we must relax that rule if curproc == updateproc ( i.e. the > syncer ), thus guarenteeing sufficient buffers for the syncer to be > able to operate in extreme conditions. > > So, to whit, I am going to start testing changes that remove the async > write code from getnewbuf() entirely and implement the emergency reserve > for updateproc. It should be fairly straightforward. I'll get the thing > reliable and then submit a patch for review. That sounds like a good idea. The syncer (I think) would write things out in a better order anyway. The writes started by getnewbuf are essentially random, as has been already noted. -- 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