Bugzilla – Bug 326
xfs_repair failing to repair corrupted dinode
Last modified: 2011-03-03 08:01:28 CST
Running xfs_repair gives the following error: corrupt dinode 92252, extent total = 3, nblocks = 0. Unmount and run xfs_repair. fatal error -- couldn't map inode 92252, err = 990 Mounting the image causes an XFS internal error dump in the kernel on 2.4 "XFS_WANT_CORRUPTED_GOTO at line 1616 of xfs_alloc.c" (snapshot snapshot-2.4.23-2003-12-01_00:33_UTC [from Knoppix, the machine normally uses 2.4.26] and 2.6.6-rc1 "XFS internal error xfs_iformat(1) at line 475 of file fs/xfs/xfs_inode.c." Full log at: http://members.uwcs.co.uk/~zx64/hda2_repair.txt.bz2 Thanks
same problem with the latest xfs_repair from CVS, just gives a little bit different error. Tried it after xfs_repair 2.6.20 produced the same error as mentioned before. Kernel 2.6.9-rc1 is able to mount the filesystem (i didn't want to try writing...), reading works well. I'll attach the output of xfs_check and xfs_reapir. If you need some more info, just ask. Bernd
Created attachment 135 [details] log of xfs_repair, version from CVS
Created attachment 136 [details] log of xfs_check
btw.: i can't reproduce how the damage to the filesystem could happen, it was cleanly unmounted, after mounting it again there were some not really existing files, they were found but it was not possible to get any data from them. But xfs_repair corrected that allready. meta-data=/mnt/maxtor/xfs isize=256 agcount=16, agsize=2947425 blks = sectsz=512 data = bsize=4096 blocks=47158800, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=23026, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0
seems to be a dupe of #274, at least it depends on it. forgot to add the syslog: messages:Sep 1 00:11:50 think kernel: Filesystem "sda4": corrupt inode 351809283 (bad size 4398314946606 for local inode). Unmount and run xfs_repair. messages:Sep 1 00:11:50 think kernel: [<c0206a51>] xfs_iformat+0x5e1/0x5f0 messages:Sep 1 00:11:50 think kernel: [<c0207c27>] xfs_iread+0x187/0x1e0 messages:Sep 1 00:11:50 think kernel: [<c0207c27>] xfs_iread+0x187/0x1e0 messages:Sep 1 00:11:50 think kernel: [<c0207c27>] xfs_iread+0x187/0x1e0 messages:Sep 1 00:11:50 think kernel: [<c0205078>] xfs_iget_core+0xa8/0x480 messages:Sep 1 00:11:50 think kernel: [<c0205503>] xfs_iget+0xb3/0x140 messages:Sep 1 00:11:50 think kernel: [<c021f81e>] xfs_dir_lookup_int+0x8e/0x110 messages:Sep 1 00:11:50 think kernel: [<c0224b52>] xfs_lookup+0x52/0x90
Created attachment 167 [details] Log of xfs_repair 2.7.11 failure This is the output of xfs_repair -v /dev/hdb1
Created attachment 168 [details] Log of xfs_repair 2.7.11 with -n This is the output of xfs_repair -v -n /dev/hdb1 Notice the somewhat different results
Created attachment 169 [details] xfs_info for the filesystem with xfs_repair 2.7.11 problems
I'm experiencing a similar problem with xfs_repair from xfsprogs 2.7.11: rebuilding directory inode 128 corrupt dinode 25633485, extent total = 2, nblocks = 1. This is a bug. Please report it to linux-xfs@oss.sgi.com. fatal error -- couldn't map inode 25633485, err = 990 This is on a filesystem on a machine running Linux 2.6.16 that was rebooted uncleanly. Interestingly, I'm also observing the corrupted filenames (first char replaced with '/') mentioned in #229. I don't have a copy of the oops produced earlier by accessing that inode, but I can try to generate one if needed. I've included the xfs_repair and xfs_info output as attachments.
Albert, xfsprogs 2.7.18 (16th May) will fix the xfs_repair problems you are seeing.
xfsprogs 2.7.18 has been out for more than two years.