#387057 #420764 These bugs apparently correspond to SGI XFS bugzilla bug #723 at <URL:http://oss.sgi.com/bugzilla/show_bug.cgi?id=723>.
A current version of xfs_repair should not exhibit this bug any more (xfsprogs >= 2.8.16). The upstream bug report recommends the use of "xfs_repair -P" when using version 2.8.11, in order to restore some of the old, still working, 2.8.10 behaviour. Please note that apparently the "xfs_check" tool is *not* being obsoleted (contrary to what Nathan Scott writes in Debian bug report #387057), but that "xfs_check" explicitly uses a different implementation (of the same "on-disk" XFS filesystem structure spec) than "xfs_repair" in order to allow for those two tools to "cross-check" each other. (Source: SGI XFS internals tutorial at http://oss.sgi.com/projects/xfs/training/index.html) The following are instructions how to to manually repair the problem. If your root filesystem is affected, you will need to boot into a different Linux system (such as the Knoppix live CD). I got the following kernel (dmesg) message when deleting the affected directory (which had been created after running "xfs_repair" on the filesystem) from /lost+found, and then unmounting the affected filesystem (in my case, /dev/md0): --- CUT --- xfs_inotobp: xfs_imap() returned an error 22 on md0. Returning error. xfs_iunlink_remove: xfs_inotobp() returned an error 22 on md0. Returning error. xfs_inactive: xfs_ifree() returned an error = 22 on md0 xfs_force_shutdown(md0,0x1) called from line 1780 of file fs/xfs/xfs_vnodeops.c. Return address = 0xfb13f728 Filesystem "md0": I/O Error Detected. Shutting down filesystem: md0 Please umount the filesystem, and rectify the problem(s) xfs_force_shutdown(md0,0x1) called from line 424 of file fs/xfs/xfs_rw.c. Return address = 0xfb13f728 xfs_force_shutdown(md0,0x1) called from line 424 of file fs/xfs/xfs_rw.c. Return address = 0xfb13f728 --- CUT --- Because my root partition was affected, this message was also displayed on shutdown (when unmounting the root filesystem), keeping the system from powering off, and possibly also leading to some data loss. I used "xfs_check" to cross-check /dev/md0, and got the following output: --- CUT --- # xfs_check /dev/md0 link count mismatch for inode 18262829 (name ?), nlink 0, counted 2 --- CUT --- I used the following command line to display the data of the affected directory inode: --- CUT --- # xfs_db -r -c 'inode 18262829' -c print /dev/XXX --- CUT --- (Of course, you will need to adjust the inode number and partition device name with your own data.) For the following to work, you must make sure that the value of "core.nlinkv1", as printed by the previous command ("xfs_db ..."), is really "= 0" (as reported by "xfs_check"). NOTE: use the commands below only if you are absolutely sure that the affected directory is really empty! If it isn't, you must mount the filesystem, "mv" (or, if you can afford to remove the files, "rm") any files from the directory somewhere else (but do *not* remove the directory), sync, and unmount the filesystem again. I was able to remove the inconsistency using the following command (NOTE: the affected filesystem must be unmounted at that point): --- CUT --- # xfs_db -x -c 'inode XXX' -c 'write core.nextents 0' /dev/hdXX # xfs_db -x -c 'inode XXX' -c 'write core.size 0' /dev/hdXX # xfs_db -x -c 'inode XXX' -c 'write core.nlinkv1 2' /dev/hdXX # sync --- CUT --- (where the "2" value comes from the "xfs_check" message above) After that, I could re-mount the filesystem, remove the affected directory (in my case, "/lost+found/18262829"), and unmount the filesystem without any errors. Just in case, it might be a good idea to run both "xfs_repair" and "xfs_check" on the filesystem once again to ensure that there are no remaining inconsistencies. DISCLAIMER: Please note that while the XFS filesystem is apparently quite well-documented, and comes with a set of rather well-designed low-level tools (like "xfs_db"), it is still very risky to use any of the above commands on your filesystem. Some loss of data is in fact rather likely once your file system has been messed up to the point described above. I will not assume any warranty that the above commands will work for your system as well as they did for me. YOU HAVE BEEN WARNED! :) Best of luck, Markus Fleck-Graffe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
