Subject: Re: block device issues (fwd)
From: Eric Sandeen <sandeen@sgi.com>
To: "Brandon D. Valentine" <bandix@structbio.vanderbilt.edu>
Cc: linux-xfs@thebarn.com
In-Reply-To: 
	<Pine.SGI.4.43.0204051500060.116241-100000@coral.structbio.vanderbilt.edu>
References: 
	<Pine.SGI.4.43.0204051500060.116241-100000@coral.structbio.vanderbilt.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 05 Apr 2002 15:24:33 -0600
Message-Id: <1018041873.7110.36.camel@stout.americas.sgi.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@thebarn.com
Precedence: bulk

Hi Brandon - 

On Fri, 2002-04-05 at 15:02, Brandon D. Valentine wrote:

> [Not subscribed so please keep me in the Cc list]
> 
> Greetings,
> 
> This past weekend one of our Linux 2.4/XFS fileservers crashed pretty
> badly.  I am attempting to diagnose the cause of the crash so that I may
> prevent it from recurring.  My analysis so far follows.  I am hoping
> that a few of you out there might have seen this before or have ideas on
> its cause.
<snip>
> void ll_rw_block(int rw, int nr, struct buffer_head * bhs[])
> {
> ...
> 		if (buffer_delay(bh) || !buffer_mapped(bh))
> 			BUG();
> ...
> }
<snip>
> presently running RedHat 7.1 XFS (using SGI's install ISO) and the
> kernel is a known good copy of 2.4.7/XFS pulled from SGI's CVS at the
> time that this fileserver was setup

The reason that BUG() is there is that if we get to ll_rw_block, ready
to send a buffer to disk, but we have no place to put it (i.e. it's a
delalloc buffer, or it's not mapped) then we're in trouble.

How you got here, I'm not certain, but going back to debug a 2.4.7
kernel is going to be rough - there have been so many changes since
then.

We are working on a release for XFS 1.1 (yours was 1.0 or 1.0.1, I
think?) and if possible, I would suggest that you upgrade a box or two
and see how that goes.  If nothing else, the updated kernels based on
Red Hat code have some security issues fixed.  :)

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.