Re: Oops with in nfsd - 2.4.19-pre6

[Christopher Barry <cbarry@infiniconsys.com>]

On Thu, 2002-10-31 at 16:30, Chris Mason wrote:
> On Thu, 2002-10-31 at 16:08, JP Howard wrote:
> > On 31 Oct 2002 15:38:19 -0500, "Chris Mason" <mason@suse.com> said:
> > <...>
> > > The idea is that during boundless operations (creating a hole, and
> > > truncates), the journal code wasn't properly reserving log blocks. 
> > <...>
> > 
> > Chris, what can trigger this situation? We're currently running
> > data=journal on 2.4.20pre in production--are we at risk?
> > 
> 
> This bug is pretty hard to hit.  It has been in every single version of
> journaling reiserfs, including 2.2.x.  So far, we've gotten two reports
> of it in about 3 years (oddly, both were this month).
> 
> What can trigger it?  I honestly haven't been able to force the problem
> to happen, it should require a very high load of processes doing
> deletions (or hole creations), along with a very high system load in
> general.
> 
> The logging code padds all the reservations for space in the log, making
> it very hard to hit the hard limit of 1024 blocks per transactions.
> 
> Both sites that have hit the bug have a very large number of files
> (millions), meaning that metadata operations will tend to log more
> blocks, making the bug more likely.
> 
> If you have less than a million files, you'll probably never be able to
> hit it.  I'm still going to try and get the fix into 2.4.20 though.
> 
> -chris
> 
> 
Off-topic, and not meaning to scold, but _why_ are you running 2.4.20pre
in a _production_ environment anyway? Just curious.

-C