Re: 2.6.18-rc3-git3 - XFS - BUG: unable to handle kernel NULL pointer dereference at virtual address 00000078

[Paul Slootman <paul+nospam@wurtel.net>]

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.

Note that I've now put an older kernel on the system (2.6.15.6) and it
seems to be surviving longer than before, with 2.6.17.7. It would be
nice if it survived a day, as it's a backup server for a couple of
important things...

(See also my messages to the xfs list, subject "cache_purge: shake on
cache 0x5880a0 left 8 nodes!?" and "XFS internal error
XFS_WANT_CORRUPTED_GOTO".)


Paul Slootman

-
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/