From: Dave Chinner <david@fromorbit.com>
To: Michael Monnerie <michael.monnerie@is.it-management.at>
Cc: xfs@oss.sgi.com
Subject: Re: bug and fun with XFS: unable to handle kernel NULL pointer dereference
Date: Mon, 26 Jul 2010 10:18:59 +1000 [thread overview]
Message-ID: <20100726001859.GD655@dastard> (raw)
In-Reply-To: <201007260019.51568@zmi.at>
On Mon, Jul 26, 2010 at 12:19:47AM +0200, Michael Monnerie wrote:
> I just enjoy an obviously broken XFS filesystem. It was a running
> server, which I planned to migrate so I did "rsync -aHAX /
> otherhost::rsyncmodule", and experienced a "killed". At that time I
> thought it was a one time mistake, so restarted rsync, but Murphy made
> it get killed again.
>
> So I looked into dmesg, just to find this: It's the log of all messages,
> so maybe twice the same, I copy everything for reference. See attachment
> "xfs-bug.dmesg.txt".
The first occurrence is:
> Pid: 1809, comm: syslog-ng Not tainted 2.6.27.48-0.1-xen #1
That's an old kernel, and doesn't seem related to the rsync
triggered problem, even though it is the same oops signature.
> I started to look, and quickly found a funny problem: Once I mount that
> partition, I cannot unmount it again:
>
> # mount /disks/work/
> # umount /disks/work/
> umount: /disks/work: device is busy.
> (In some cases useful info about processes that use
> the device is found by lsof(8) or fuser(1))
Some other process has taken a reference to the fs, I'd say.
And if that process triggered an oops, then you'd see this.
> So I rebooted without mounting that partition, and
>
> # xfs_repair -n /dev/xvda2 [VERSION:3.1.2]
> xfs_repair: /lib64/libuuid.so.1: no version information available
> (required by xfs_repair)
> Phase 1 - find and verify superblock...
> Phase 2 - using internal log
> - scan filesystem freespace and inode maps...
> - found root inode chunk
> Phase 3 - for each AG...
> - scan (but don't clear) agi unlinked lists...
> - process known inodes and perform inode discovery...
> - agno = 0
> - agno = 1
> local inode 8636461 attr too small (size = 0, min size = 4)
> bad attribute fork in inode 8636461, would clear attr fork
> would have cleared inode 8636461
Corrupt attribute fork - matches with the oops signatures. I'd
definitely consider upgrading your kernel as a first step...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-07-26 0:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-25 22:19 bug and fun with XFS: unable to handle kernel NULL pointer dereference Michael Monnerie
2010-07-26 0:18 ` Dave Chinner [this message]
2010-07-26 5:52 ` permanent kernel upgrading (was: bug and fun with XFS: unable to handle kernel NULL pointer dereference) Michael Monnerie
2010-07-26 7:17 ` Dave Chinner
2010-07-26 8:43 ` Michael Monnerie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100726001859.GD655@dastard \
--to=david@fromorbit.com \
--cc=michael.monnerie@is.it-management.at \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.