From: Eric Sandeen <sandeen@sandeen.net>
To: Martin Michlmayr <tbm@cyrius.com>
Cc: Tobias Frost <tobi@coldtobi.de>,
linux-kernel@vger.kernel.org, debian-arm@lists.debian.org,
xfs@oss.sgi.com
Subject: Re: XFS filesystem corruption on the arm(el) architecture
Date: Thu, 16 Oct 2008 17:13:51 -0500 [thread overview]
Message-ID: <48F7BC9F.4080909@sandeen.net> (raw)
In-Reply-To: <20081016212500.GA27228@deprecation.cyrius.com>
Martin Michlmayr wrote:
> Hi Eric,
>
> I tried to reproduce this problem on my ARM machine and it's really
> easy to trigger. See the transcript below.
>
> I tried with 2.6.26.6 (without the ARM old ABI fix) and 2.6.27 (with
> the fix), and with xfsprogs 2.9.8-1.
>
> Note that I'm actually using the ARM EABI, and not the old ABI.
> I'm not sure what Tobias used.
>
> xfs.ko compiled with -g can be found at http://www.cyrius.com/tmp/xfs.ko.bz2
> (3.1 MB)
Thanks; a quick look at the disk structure sizes & offsets shows no
differences (as I'd hope/expect for ARM EABI).
> Here's the transcript. It's really easy to trigger. Just copy some
> files to the XFS partition (works) and then run 'ls' (oops):
So is this a regression? did it used to work? If so, when? :)
(just for the record; it didn't oops, it shut down the filesystem and
gave you a backtrace to the error...)
It's trying to get a buffer for a directory leaf block from disk, and
it's finding that the magic number is bad.
What's a little odd is that the buffer it dumped out looks like the
beginning of a perfectly valid superblock for your filesystem (magic,
block size, and block count all match). If you printk the "bno"
variable right around line 2106 in xfs_da_btree.c, can you see what you get?
creating an xfs_metadump of the filesystem for examination on a non-arm
box might also be interesting.
Thanks,
-Eric
> debian:~# modprobe xfs
> debian:~# mkfs.xfs -f /dev/sda6
> meta-data=/dev/sda6 isize=256 agcount=4, agsize=17778431 blks
> = sectsz=512 attr=2
> data = bsize=4096 blocks=71113722, imaxpct=25
> = sunit=0 swidth=0 blks
> naming =version 2 bsize=4096
> log =internal log bsize=4096 blocks=32768, version=2
> = sectsz=512 sunit=0 blks, lazy-count=0
> realtime =none extsz=4096 blocks=0, rtextents=0
> debian:~# dmesg | tail -n 2
> [42949548.970000] SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled
> [42949548.980000] SGI XFS Quota Management subsystem
> debian:~# mount /dev/sda6 /mnt
> debian:~# dmesg | tail -n 2
> [42949596.470000] XFS mounting filesystem sda6
> [42949596.610000] Ending clean XFS mount for filesystem: sda6
> debian:~# cp /usr/bin/* /mnt/
> debian:~# dmesg | tail -n 2
> [42949596.470000] XFS mounting filesystem sda6
> [42949596.610000] Ending clean XFS mount for filesystem: sda6
> debian:~# ls /mnt
> ls: reading directory /mnt: Structure needs cleaning
> debian:~# dmesg | tail -n 16
> [42949596.610000] Ending clean XFS mount for filesystem: sda6
> [42949619.790000] 00000000: 58 46 53 42 00 00 10 00 00 00 00 00 04 3d 1b fa XFSB.........=..
> [42949619.800000] Filesystem "sda6": XFS internal error xfs_da_do_buf(2) at line 2107 of file fs/xfs/xfs_da_btree.c. Caller 0xbf148b44
> [42949619.820000] [<c002a370>] (dump_stack+0x0/0x14) from [<bf154968>] (xfs_error_report+0x4c/0x5c [xfs])
> [42949619.820000] [<bf15491c>] (xfs_error_report+0x0/0x5c [xfs]) from [<bf1549d4>] (xfs_corruption_error+0x5c/0x68 [xfs])
> [42949619.830000] r4:c7914400
> [42949619.840000] [<bf154978>] (xfs_corruption_error+0x0/0x68 [xfs]) from [<bf1489b8>] (xfs_da_do_buf+0x554/0x654 [xfs])
> [42949619.850000] r6:bf148b44 r5:00000000 r4:c7073418
> [42949619.850000] [<bf148464>] (xfs_da_do_buf+0x0/0x654 [xfs]) from [<bf148b44>] (xfs_da_read_buf+0x34/0x3c [xfs])
> [42949619.860000] [<bf148b10>] (xfs_da_read_buf+0x0/0x3c [xfs]) from [<bf14edec>] (xfs_dir2_leaf_getdents+0x480/0x8b4 [xfs])
> [42949619.880000] [<bf14e96c>] (xfs_dir2_leaf_getdents+0x0/0x8b4 [xfs]) from [<bf14b07c>] (xfs_readdir+0xcc/0xe0 [xfs])
> [42949619.890000] [<bf14afb0>] (xfs_readdir+0x0/0xe0 [xfs]) from [<bf18140c>] (xfs_file_readdir+0x144/0x194 [xfs])
> [42949619.900000] [<bf1812c8>] (xfs_file_readdir+0x0/0x194 [xfs]) from [<c009ffb0>] (vfs_readdir+0x84/0xb8)
> [42949619.910000] [<c009ff2c>] (vfs_readdir+0x0/0xb8) from [<c00a0050>] (sys_getdents64+0x6c/0xc0)
> [42949619.920000] [<c009ffe4>] (sys_getdents64+0x0/0xc0) from [<c0025bc0>] (ret_fast_syscall+0x0/0x3c)
> [42949619.930000] r7:000000d9 r6:0002a01c r5:0002a030 r4:00000000
> debian:~#
>
next prev parent reply other threads:[~2008-10-16 22:13 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-01 20:38 XFS filesystem corruption on the arm(el) architecture Tobias Frost
2008-10-02 0:45 ` Dave Chinner
2008-10-02 0:56 ` Eric Sandeen
2008-10-02 1:17 ` Eric Sandeen
2008-10-16 21:25 ` Martin Michlmayr
2008-10-16 22:13 ` Eric Sandeen [this message]
2008-10-17 7:01 ` Martin Michlmayr
2008-10-17 9:46 ` Gaudenz Steinlin
2008-10-17 13:49 ` Eric Sandeen
2008-10-18 13:11 ` Tobias Frost
2008-10-18 19:48 ` Kirill A. Shutemov
2008-10-18 20:09 ` Christoph Hellwig
2008-10-18 20:17 ` Kirill A. Shutemov
2008-10-17 14:15 ` Eric Sandeen
2008-10-18 8:57 ` Martin Michlmayr
2008-10-18 14:48 ` Eric Sandeen
2008-10-19 1:48 ` Dave Chinner
2008-10-19 3:06 ` Eric Sandeen
2008-10-19 9:07 ` Christoph Hellwig
2008-10-19 16:22 ` Lennert Buytenhek
2008-10-19 5:12 ` Martin Michlmayr
2008-10-02 1:42 ` Eric Sandeen
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=48F7BC9F.4080909@sandeen.net \
--to=sandeen@sandeen.net \
--cc=debian-arm@lists.debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tbm@cyrius.com \
--cc=tobi@coldtobi.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 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.