Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Feb 1999 10:08:18 +0000 (GMT)
From:      Doug Rabson <dfr@nlsystems.com>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Luoqi Chen <luoqi@watermarkgroup.com>, freebsd-hackers@freebsd.org, mjacob@feral.com
Subject:   Re: Panic in FFS/4.0 as of yesterday - update
Message-ID:  <Pine.BSF.4.05.9902251001320.67660-100000@herring.nlsystems.com>
In-Reply-To: <199902250916.BAA02250@apollo.backplane.com>

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9902251001320.67660-100000>