From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: "Brian Foster" <bfoster@redhat.com>,
"Luca Gibelli" <luca@skylable.com>,
xfs@oss.sgi.com,
"Christopher Squires" <christopher.squires@hgst.com>,
"Török Edwin" <edwin@skylable.com>,
"Wayne Burri" <wayne.burri@hgst.com>
Subject: Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
Date: Fri, 12 Jun 2015 08:53:08 +1000 [thread overview]
Message-ID: <20150611225308.GF24666@dastard> (raw)
In-Reply-To: <5579EA91.3090707@sandeen.net>
On Thu, Jun 11, 2015 at 03:07:45PM -0500, Eric Sandeen wrote:
> On 6/11/15 11:32 AM, Török Edwin wrote:
> > [4745016.650000] XFS (loop0): metadata I/O error: block 0xa000 ("xfs_trans_read_buf_map") error 117 numblks 8
>
> ok, block 0xA000 (in sectors) is sector 40960...
>
> xfs_db> daddr 40960
> xfs_db> fsblock
> current fsblock is 8192
> xfs_db> type text
> xfs_db> p
> 000: 58 46 53 42 00 00 10 00 00 00 00 00 00 00 28 00 XFSB............
> 010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 020: 64 23 d2 06 32 2e 4c 20 82 6e f0 36 a7 d9 54 f9 d...2.L..n.6..T.
>
> ...
>
> Right, so it's reading the 2nd superblock in xfs_dir3_data_read_verify. Huh?
> (I could have imagined some weird scenario where we read block 0, but 8192?
> Very strange).
>
> Hm, I don't think this can be readahead, it'd not get to this verifier AFAICT.
>
> Given that the image is enough to reproduce via just mount; ls - we should be
> able to reproduce this, given the right hardware, and get to the bottom of it.
OK, so I've had a look at the on disk layout via xfs_db and there is
no corruption present on disk. I've confirmed that by mounting on
x86-64 (on 4.1-rc6) and no errors have been issued, and xfs_repair
(from for-next branch) doesn't see anything wrong, either.
So this is looking like either: a) a kernel bug we've subsequently
fixed; or b) an arm specific compiler or kernel bug.
I'd like to see a) ruled out as quickly as possible. Torok, can you
build a more recent kernel and see if the problem persists?
Can you also let us know what compiler version you are using and how
you are compiling (e.g. cross compile)? ISTR a previous incarnation
of this problem showed up when a specific compiler version was used
to cross-compile the armv7 kernel from x86-64, and it went away with
a compiler update. So it would be good to rule out the
compiler/build environment as the cause, too.
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:[~2015-06-11 22:53 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-11 6:23 PROBLEM: XFS on ARM corruption 'Structure needs cleaning' Török Edwin
2015-06-11 15:16 ` Brian Foster
2015-06-11 15:28 ` Török Edwin
2015-06-11 15:51 ` Eric Sandeen
2015-06-11 15:58 ` Eric Sandeen
2015-06-11 16:32 ` Török Edwin
2015-06-11 17:10 ` Eric Sandeen
2015-06-11 17:13 ` Török Edwin
2015-06-11 17:16 ` Eric Sandeen
2015-06-11 20:07 ` Eric Sandeen
2015-06-11 20:29 ` Eric Sandeen
2015-06-11 22:53 ` Dave Chinner [this message]
2015-06-12 12:21 ` Brian Foster
2015-06-12 12:47 ` Török Edwin
2015-06-12 13:54 ` Brian Foster
2015-06-12 20:19 ` Eric Sandeen
[not found] ` <BLUPR04MB593340A765596780F266454F2BB0@BLUPR04MB593.namprd04.prod.outlook.com>
2015-06-13 13:55 ` Török Edwin
2015-06-12 22:52 ` Dave Chinner
2015-08-12 0:56 ` katsuki.uwatoko
2015-08-12 0:56 ` katsuki.uwatoko at toshiba.co.jp
2015-08-12 3:14 ` Dave Chinner
2015-08-12 3:14 ` Dave Chinner
2015-08-12 6:19 ` katsuki.uwatoko
2015-08-12 6:19 ` katsuki.uwatoko at toshiba.co.jp
2015-08-12 6:24 ` enabling libgcc for 64-bit divisions, was " Christoph Hellwig
2015-08-12 6:24 ` Christoph Hellwig
2015-08-12 15:49 ` Linus Torvalds
2015-08-12 15:49 ` Linus Torvalds
2015-08-12 22:20 ` Andy Lutomirski
2015-08-12 22:20 ` Andy Lutomirski
2015-08-12 22:36 ` Linus Torvalds
2015-08-12 22:36 ` Linus Torvalds
2015-08-12 22:39 ` Andy Lutomirski
2015-08-12 22:39 ` Andy Lutomirski
2015-08-13 3:28 ` Andrew Morton
2015-08-13 3:28 ` Andrew Morton
2015-10-08 15:50 ` Pavel Machek
2015-10-08 15:50 ` Pavel Machek
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=20150611225308.GF24666@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=christopher.squires@hgst.com \
--cc=edwin@skylable.com \
--cc=luca@skylable.com \
--cc=sandeen@sandeen.net \
--cc=wayne.burri@hgst.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.