Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758037AbYJPWPv (ORCPT ); Thu, 16 Oct 2008 18:15:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757363AbYJPWPd (ORCPT ); Thu, 16 Oct 2008 18:15:33 -0400 Received: from mx2.redhat.com ([66.187.237.31]:47304 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755970AbYJPWPb (ORCPT ); Thu, 16 Oct 2008 18:15:31 -0400 Message-ID: <48F7BC9F.4080909@sandeen.net> Date: Thu, 16 Oct 2008 17:13:51 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Martin Michlmayr CC: Tobias Frost , linux-kernel@vger.kernel.org, debian-arm@lists.debian.org, xfs@oss.sgi.com Subject: Re: XFS filesystem corruption on the arm(el) architecture References: <1222893502.5020.40.camel@moria> <20081002004556.GB30001@disturbed> <48E4213E.9090508@sandeen.net> <20081016212500.GA27228@deprecation.cyrius.com> In-Reply-To: <20081016212500.GA27228@deprecation.cyrius.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4520 Lines: 88 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] [] (dump_stack+0x0/0x14) from [] (xfs_error_report+0x4c/0x5c [xfs]) > [42949619.820000] [] (xfs_error_report+0x0/0x5c [xfs]) from [] (xfs_corruption_error+0x5c/0x68 [xfs]) > [42949619.830000] r4:c7914400 > [42949619.840000] [] (xfs_corruption_error+0x0/0x68 [xfs]) from [] (xfs_da_do_buf+0x554/0x654 [xfs]) > [42949619.850000] r6:bf148b44 r5:00000000 r4:c7073418 > [42949619.850000] [] (xfs_da_do_buf+0x0/0x654 [xfs]) from [] (xfs_da_read_buf+0x34/0x3c [xfs]) > [42949619.860000] [] (xfs_da_read_buf+0x0/0x3c [xfs]) from [] (xfs_dir2_leaf_getdents+0x480/0x8b4 [xfs]) > [42949619.880000] [] (xfs_dir2_leaf_getdents+0x0/0x8b4 [xfs]) from [] (xfs_readdir+0xcc/0xe0 [xfs]) > [42949619.890000] [] (xfs_readdir+0x0/0xe0 [xfs]) from [] (xfs_file_readdir+0x144/0x194 [xfs]) > [42949619.900000] [] (xfs_file_readdir+0x0/0x194 [xfs]) from [] (vfs_readdir+0x84/0xb8) > [42949619.910000] [] (vfs_readdir+0x0/0xb8) from [] (sys_getdents64+0x6c/0xc0) > [42949619.920000] [] (sys_getdents64+0x0/0xc0) from [] (ret_fast_syscall+0x0/0x3c) > [42949619.930000] r7:000000d9 r6:0002a01c r5:0002a030 r4:00000000 > debian:~# > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/