|UNICOS/mpTM Disks and File Systems Administration - S-2377-22|
|Prev Section||Chapter 7. Maintaining XFS File Systems||Next Section|
The xfs_repair command checks XFS file system consistency and sometimes repairs problems that are found. This section describes the messages that you may see from xfs_repair and what to do if xfs_repair is not able to repair a file system.
Common error messages from xfs_repair, and the repairs that it performs, include the following:
|disconnected inode 242002, moving to lost+found|
xfs_repair found an inode that is in use, but is not connected to the file system. The inode is moved to the file system's lost+found directory. Its name is its inode number, in this example 242002. If the disconnected inode is a directory, the directory's subtree is preserved—all its child inodes are automatically moved with it, so the entire directory subtree moves to lost+found.
|imap claims in-use inode 2444941 is free, correcting imap|
The inode allocation map in the file system behaves as if inode 2444941 is free, but the inode itself looks like it is still in use. xfs_repair corrects the inode map to say that the inode is in use.
|entry references free inode 2444940 in shortform directory 2444922 junking entry “fb” in directory inode 2444922|
A directory entry points to an inode that xfs_repair has determined is actually free. xfs_repair junks the directory entry. The term shortform means a small directory. In larger directories, the entry deletion is usually a two-pass process. In this case, the second part of the message reads something like marking bad entry, marking entry to be deleted, or will clear entry.
|resetting inode 241996 nlinks from 5 to 3|
xfs_repair detected a mismatch between the number of directory entries pointing to the inode (links) and the number of links recorded in the inode. It corrected the number (from 5 to 3 in this case).
|cleared inode 2444926|
There was something wrong with the inode that was not correctable, so xfs_repair turned it into a zero-length free inode. This usually happens because the inode claims blocks that are used by something else or the inode itself is badly corrupted. Typically, the cleared inode message is preceded by one or more messages indicating why the inode needs to be cleared.
If xfs_repair has put files and directories in a file system's lost+found directory and you do not remove them, the next time you run xfs_repair it temporarily disconnects the inodes for those files and directories. They are reconnected before xfs_repair terminates. As a result of the disconnected inodes in lost+found, you see output like this:
Phase 1 - find and verify superblock... Phase 2 - zero log... - scan file system freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 ... - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing “lost+found” inode - deleting existing “lost+found” entry - check for inodes claiming duplicate blocks... - agno = 0 imap claims in-use inode 242000 is free, correcting imap - agno = 1 - agno = 2 ... Phase 5 - rebuild AG headers and trees... - reset superblock counters... Phase 6 - check inode connectivity... - ensuring existence of lost+found directory - traversing file system starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 242000, moving to lost+found Phase 7 - verify and correct link counts... done
In this example, inode 242000 was an inode that was moved to lost+found during a previous xfs_repair run. This run of xfs_repair found that the file system is consistent. If the lost+found directory had been empty, in phase 4 only the messages about clearing and deleting the lost+found directory would have appeared. The left-justified imap claims and disconnected inode messages appear (one pair of messages per inode) if there are inodes in the lost+found directory.
If xfs_repair fails to repair the file system successfully, try giving the same xfs_repair command twice more; xfs_repair may be able to make more repairs on successive runs. If xfs_repair fails to fix the consistency problems in three tries, your next step depends upon where it failed:
If xfs_repair failed in phase 1, you must restore lost files from backups.
If xfs_repair failed in phase 2 or later, you may be able to restore files from the disk by backing up and restoring the files on the file system.
If xfs_repair failed in phase 2 or later, follow these steps:
Mount the file system using mount -r (read-only).
Make a file system backup with xfsdump.
Use mkfs to a make new file system on the same disk partition or XLV logical volume.
Restore the files from the backup with xfsrestore.
If a file system is damaged to the extent that you are unable to mount the file system successfully in the standard fashion, you may be able to recover some of its data by mounting the file system with the -o norecover option of the mount command. This option mounts the file system without running log recovery. You must mount the file system as read-only when you use this option.
When you mount the file system in no-recovery mode when it was not unmounted cleanly, the file system is likely to be inconsistent, and you will be unable to read all of its data. However, you may be able to recover data that you can cannot otherwise access.
For information on the mount command and its options, see the mount(8) and the fstab(5) man pages.