From: Dave Chinner <david@fromorbit.com>
To: Dave Jones <davej@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: XFS: Internal error XFS_WANT_CORRUPTED_RETURN
Date: Thu, 12 Dec 2013 10:01:28 +1100 [thread overview]
Message-ID: <20131211230128.GM10988@dastard> (raw)
In-Reply-To: <20131211172725.GA4606@redhat.com>
On Wed, Dec 11, 2013 at 12:27:25PM -0500, Dave Jones wrote:
> Powered up my desktop this morning and noticed I couldn't cd into ~/Mail
> dmesg didn't look good. "XFS: Internal error XFS_WANT_CORRUPTED_RETURN"
> http://codemonkey.org.uk/junk/xfs-1.txt
They came from xfs_dir3_block_verify() on read IO completion, which
indicates that the corruption was on disk and in the directory
structure. Yeah, definitely a verifier error:
XFS (sda3): metadata I/O error: block 0x2e790 ("xfs_trans_read_buf_map") error 117 numblks 8
Are you running a CRC enabled filesystem? (i.e. mkfs.xfs -m crc=1)
Is there any evidence that this verifier has fired in the past on
write? If not, then it's a good chance that it's a media error
causing this, because the same verifier runs when the metadata is
written to ensure we are not writing bas stuff to disk.
> I rebooted into single user mode, and ran xfs_repair on /dev/sda3 (/home).
> It fixed up a bunch of stuff, but ended up eating ~/.procmailrc entirely
> (no sign of it in lost & found), and a bunch of filenames got garbled
> 'december' became 'decemcer' for eg. Looks like a couple kernel trees ended
> up in lost & found.
Single bit errors in directory names? That really does point towards
media errors, not a filesystem error being the cause.
> After rebooting back into multi-user mode, I looked in dmesg again to be sure
> and this time sda2 was complaining..
>
> http://codemonkey.org.uk/junk/xfs-2.txt
Exaclty the same - directory blocks failing read verification.
> Same drill, reboot, xfs_repair. Looks like a bunch of man pages ended up in lost & found.
>
> Thoughts ? Could sda be dying ? (It is a fairly old crappy ssd)
I'd seriously be considering replacing the SSD as the first step.
If you then see failures on a known good drive, we'll need to dig
further.
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:[~2013-12-11 23:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-11 17:27 XFS: Internal error XFS_WANT_CORRUPTED_RETURN Dave Jones
2013-12-11 18:52 ` Chris Murphy
2013-12-11 18:57 ` Dave Jones
2013-12-12 0:19 ` Chris Murphy
2013-12-13 9:46 ` Stan Hoeppner
2013-12-11 23:01 ` Dave Chinner [this message]
2013-12-12 16:14 ` Eric Sandeen
2013-12-12 16:20 ` Dave Jones
2013-12-12 21:27 ` Dave Chinner
-- strict thread matches above, loose matches on Subject: below --
2007-08-23 20:09 XFS internal " Markus Schoder
2007-08-24 1:43 ` David Chinner
2007-08-24 19:19 ` Markus Schoder
2007-08-24 2:02 ` Timothy Shimmin
2007-08-24 19:23 ` Markus Schoder
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=20131211230128.GM10988@dastard \
--to=david@fromorbit.com \
--cc=davej@redhat.com \
--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.