# 不修改检查文件系统
xfs_repair -n /dev/sda5
# 修复文件系统
xfs_repair /dev/sda5
# 不使用log记录修复
xfs_repair -L /dev/sda5
Usage: xfs_repair [options] device
Options:
-f The device is a file
-L Force log zeroing. Do this as a last resort.
-l logdev Specifies the device where the external log resides.
-m maxmem Maximum amount of memory to be used in megabytes.
-n No modify mode, just checks the filesystem for damage.
-P Disables prefetching.
-r rtdev Specifies the device where the realtime section resides.
-v Verbose output.
-c subopts Change filesystem parameters – use xfs_admin.
-o subopts Override default behaviour, refer to man page.
-t interval Reporting interval in minutes.
-d Repair dangerously.
-V Reports version and exits.
man page:
-n No modify mode.
Specifies that xfs_repair should not modify the filesystem but
should only scan the filesystem and indicate what repairs would have been made.
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.