lkml.org 
[lkml]   [2006]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.18-rc3-git3 - XFS - BUG: unable to handle kernel NULL pointer dereference at virtual address 00000078
On Wed, Aug 16, 2006 at 12:38:10PM +0000, Paul Slootman wrote:
> Nathan Scott <nathans@sgi.com> wrote:
> >On Fri, Aug 11, 2006 at 12:25:03PM +0200, Jesper Juhl wrote:
> >> I didn't capture all of the xfs_repair output, but I did get this :
> >> ...
> >> Phase 4 - check for duplicate blocks...
> >> - setting up duplicate extent list...
> >> - clear lost+found (if it exists) ...
> >> - clearing existing "lost+found" inode
> >> - deleting existing "lost+found" entry
> >> - check for inodes claiming duplicate blocks...
> >> - agno = 0
> >> - agno = 1
> >> - agno = 2
> >> - agno = 3
> >> - agno = 4
> >> - agno = 5
> >> - agno = 6
> >> LEAFN node level is 1 inode 412035424 bno = 8388608
> >Ooh. Can you describe this test case you're using? Something with
> >a bunch of renames in it, obviously, but I'd also like to be able to
> >reproduce locally with the exact data set (file names in particular),
> >if at all possible.
>
> >From your reaction above I gather that "LEAFN node level is 1 inode ..."
> is a bad thing?
>
> My filesystem (that crashes under heavy load, while rsyncing to and from
> it) has a lot of these messages when xfs_repair is run.

Do you have a reproducible test case? Please send a go-to-woe recipe
so I can see the problem first hand... and preferably one that is, er,
slightly simpler than Jesper's case.

thanks.

--
Nathan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-08-17 00:51    [from the cache]
©2003-2011 Jasper Spaans