[Top] [All Lists]

Re: block device issues (fwd)

To: "Brandon D. Valentine" <bandix@xxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: block device issues (fwd)
From: Eric Sandeen <sandeen@xxxxxxx>
Date: 05 Apr 2002 15:24:33 -0600
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <Pine.SGI.4.43.0204051500060.116241-100000@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <Pine.SGI.4.43.0204051500060.116241-100000@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
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.
> void ll_rw_block(int rw, int nr, struct buffer_head * bhs[])
> {
> ...
>               if (buffer_delay(bh) || !buffer_mapped(bh))
>                       BUG();
> ...
> }
> 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

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 Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@xxxxxxx   SGI, Inc.

<Prev in Thread] Current Thread [Next in Thread>