public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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:~#
> 


  reply	other threads:[~2008-10-16 22:15 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox