From: Dave Chinner <david@fromorbit.com>
To: Sascha Askani <saskani@inovex.de>
Cc: xfs@oss.sgi.com
Subject: Re: Weird XFS Corruption Error
Date: Sat, 25 Jan 2014 08:52:57 +1100 [thread overview]
Message-ID: <20140124215257.GA26397@dastard> (raw)
In-Reply-To: <FF1E62DE-5CFC-469B-BBF7-F5AB04AD4C0C@inovex.de>
On Fri, Jan 24, 2014 at 08:56:32AM +0100, Sascha Askani wrote:
> Hi Dave,
>
> thanks for your reply and I’m sorry for the delayed answer…
>
> Am 23.01.2014 um 00:31 schrieb Dave Chinner <david@fromorbit.com>:
>
> > On Wed, Jan 22, 2014 at 05:09:10PM +0100, Sascha Askani wrote:
> >
> > So, an inode extent map btree block failed verification for some
> > reason. Hmmm - there should have been 4 lines of hexdump output
> > there as well. Can you post that as well? Or have you modified
> > /proc/sys/fs/xfs/error_level to have a value of 0 so it is not
> > emitted?
> >
>
> /proc/sys/fs/xfs/error_level is set to 3, sorry for not including this in my original post, the Hexdump is pretty „boring“ (or interesting, depending on your point of view):
>
> [964197.435322] ffff881f8e59b000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [964197.862037] ffff881f8e59b010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [964198.288694] ffff881f8e59b020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> [964198.712093] ffff881f8e59b030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Yeah, that confirms what I suspected - the buffer has been
overwritten with zeros. That tends to imply *something* has zeroed
the start of the block device, and that's the cause of all the
problems.
> > Oh, wow. Ok, if the primary superblock is gone, along with metadata
> > in the first few blocks of the filesystem, then something has
> > overwritten the start of the block device the filesystem is on.
> >
> >> 2. mounted the filesystem, which gave me a „Structure needs cleaning“ after a couple of seconds
> >> 3. tried mounting again for good measure, same error „Structure needs cleaning“
> >
> > Right - the kernel can't read a valid superlock, either.
>
> Just seen this messages in the log which were emitted when trying to mount the FS:
>
> [964606.038733] XFS (dm-8): metadata I/O error: block 0x200 ("xlog_recover_do..(read#2)") error 117 numblks 16
> [964606.515048] XFS (dm-8): log mount/recovery failed: error 117
> [964606.515386] XFS (dm-8): log mount failed
Yup, that's trying to read an inode cluster. It's also right near
the start of the filesystem (0x200 * 512 bytes = 256k into the
filesystem) So log recovery is trying to replay an inode change and
finding the inodes that underly the change in the log are corrupt.
This really looks like something outside the filesystem caused the
problem. It's probably too late to find out what caused it either,
but I'd be checking with your HW vendor(s) about known problems with
their hardware/firmware....
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:[~2014-01-24 21:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-22 16:09 Weird XFS Corruption Error Sascha Askani
2014-01-22 23:31 ` Dave Chinner
2014-01-24 7:56 ` Sascha Askani
2014-01-24 21:52 ` Dave Chinner [this message]
2014-01-23 14:19 ` Emmanuel Florac
2014-01-23 14:29 ` Emmanuel Florac
2014-01-24 8:08 ` Sascha Askani
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=20140124215257.GA26397@dastard \
--to=david@fromorbit.com \
--cc=saskani@inovex.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox