If you cannot mount an XFS file system, get i/o error or 'mount: Structure needs cleaning', then you will have to repair xfs filesystem after underneath storage problem fixed.
Check xfs filesystem
If you are running xfs xfsprogs-3.1.1 on RHEL6, on you can use the xfs_check command to check its consistency. On xfsprogs-3.2.2-2, you have only xfs_repair to check its consistency. xfs_repair is available on both versions.
Usually, you would only run this command on the device file of an unmounted file system that you believe has a problem. If xfs_check displays any output when you do not run it in verbose mode, the file system has an inconsistency.
umount the file system, then run command below
# xfs_repair -n device
Note: Unlike fsck, neither xfs_check nor xfs_repair are invoked automatically on system startup. They should be used only if you suspect a file system consistency problem.
Backup xfs filesystem
If you can mount the file system and you do not have a suitable backup, you can use xfsdump to attempt to back up the existing file system data, However, the command might fail if the file system's metadata has become too corrupted.
Or you can use xfs_copy to backup a xfs filesystem
xfs filesystem repair
You can use the xfs_repair command to attempt to repair an XFS file system specified by its device file. The command replays the journal log to fix any inconsistencies that might have resulted from the file system not being cleanly unmounted. Unless the file system has an inconsistency, it is usually not necessary to use the command, as the journal is replayed every time that you mount an XFS file system.
If the journal log has become corrupted, you can reset the log by specifying the -L option to xfs_repair.
Note: Resetting the log can leave the file system in an inconsistent state, resulting in data loss and data corruption. Unless you are experienced in debugging and repairing XFS file systems using xfs_db, it is recommended that you instead recreate the file system and restore its contents from a backup.
If you cannot mount the file system or you do not have a suitable backup, running xfs_repair is the only viable option unless you are experienced in using xfs_db.
xfs_db provides an internal command set that allows you to debug and repair an XFS file system manually. The commands allow you to perform scans on the file system, and to navigate and display its data structures. If you specify the -x option to enable expert mode, you can modify the data structures.
xfs_db [-x] device
For more information, see the
xfs_repair(8) manual pages, and the help command within xfs_db.
Repairing XFS File System Problems
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
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.
Error Messages When Files Are in lost+found
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.
What to Do If xfs_repair Cannot Repair a File System
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.
Mounting A File System without Log Recovery
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.