If you're attempting to run xfs_repair, getting the error message that suggests mounting the filesystem to replay the log, and after mounting still receiving the same error message, you may need to perform a forced repair (using the -L flag with xfs_repair). This option should be a last resort.
For example, I'll use a case where I had a corrupt root partition on my CentOS 7 install. When attempting to mount the partition, I continually received the below error message:
mount: mount /dev/mapper/centos-root on /mnt/centos-root failed: Structure needs cleaning
Unfortunately, forcing a repair would involve zeroing out (destroying) the log before attempting a repair. When using this method, there is a potential of ending up with more corrupt data than initially anticipated; however, we can use the appropriate xfs tools to see what kind of damage may be caused before making any permanent changes.
Using xfs_metadump and xfs_mdrestore, you can create a metadata image of the affected partition and perform the forced repair on the image rather than the partition itself. The benefits of this is the ability to see the damage that comes with a forced repair before performing it on the partition.
To do this, you'll need a decent sized USB or external hard drive. Start by mounting the USB drive - my USB was located at /dev/sdb1, yours may be named differently.
mkdir -p /mnt/usb
mount /dev/sdb1 /mnt/usb
Once mounted, run xfs_metadump to create a copy of the partition metadata to the USB - again, your affected partition may be different. In this case, I had a corrupt root partition located at /dev/mapper/centos-root:
xfs_metadump /dev/mapper/centos-root /mnt/usb/centos-root.metadump
Next, you'll want to restore the metadata in to an image so that we can perform a repair and measure the damage.
xfs_mdrestore /mnt/usb/centos-root.metadump /mnt/usb/centos-root.img
I found that in rescue mode xfs_mdrestore is not available, and instead you'll need to be in rescue mode of a live CentOS CD.
Finally, we can perform the repair on the image:
xfs_repair -L /mnt/usb/centos-root.img
After the repair has completed and you've assessed the output and potential damage, you can determine as to whether you'd like to perform the repair against the partition.
To run the repair against the partition, simply run:
xfs_repair -L /dev/mapper/centos-root
Don't forget to check the other partitions for corruption as well. After the repairs, reboot the system and you should be able to successfully boot.
Remember that the -L flag should be used as a last resort where there are no other possible options to repair.
https://serverfault.com/questions/777299/proper-way-to-deal-with-corrupt-xfs-filesystems
https://serverfault.com/questions/851204/risk-of-not-repairing-structure-needs-cleaning-xfs-errors
https://unix.stackexchange.com/questions/330742/cannot-remove-file-structure-needs-cleaning
http://xfs.9218.n7.nabble.com/mount-Structure-needs-cleaning-td2796.html
fsck -vcfy /dev/sda3 會清空數據。
我的移動硬盤也遇到這個問題，同樣是XFS文件系統。 在未掛載狀態下試一試這個命令： # xfs_repair /dev/sdb1 /*后面跟目標驅動器路徑*/ 如果提示log什么的有問題，則使用-L參數,這會重建log，然后再使用上面一條命令進行修復。 #xfs_repair -L /dev/sdb1
1 執行debugfs -w /dev/sdb (/dev/sdb出現 該情況文件所在的分區) -w says that partition will be opened in read-write mode.
2 mount /dev/sdb /mnt/other 掛載到mnt/other 目錄下
3 執行 clri path/file 移除損壞文件節點 注意path/file 值的是相對路徑 而不是/mnt/other/****
4 退出 debugfs 執行fsck -y /mnt/other 修復該分區
ext4文件系統，使用命令 fsck.ext4 /dev/md0 修復，
如果是xfs文件系統，使用命令 xfs_repair -L /dev/md0修復，
# mount /dev/sdb1 /disk2
mount: Structure needs cleaning
我用了下列的指令解決了. 雖然我不太清楚什麼東西導致它有問題 :
# xfs_repair -n /dev/sdb1
上面指令還不能完全解決
# xfs_check /dev/sdb1
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed. Mount the filesystem to replay the log, and unmount it before
re-running xfs_check. If you are unable to mount the filesystem, then use
the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption — please attempt a mount
of the filesystem before doing this.
用 xfs_check 指令. 它建議我用 “xfs_repair -L ”
# xfs_repair -L /dev/sdb1
這樣弄玩之後. 在用 xfs_check 檢查一次
# xfs_check /dev/sdb1
就可以掛載了
# mount /dev/sdb1 /disk2
[root@pc4 ~]# mount /data2
mount: Structure needs cleaning
[root@pc4 ~]# xfs_repair -L /dev/vgcb0
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
ALERT: The filesystem has valuable metadata changes in a log which is being
destroyed because the -L option was used.
- scan filesystem freespace and inode maps...
agi unlinked bucket 16 is 252816 in ag 0 (inode=252816)
sb_icount 2977088, counted 2639872
sb_ifree 1752667, counted 1398980
sb_fdblocks 243437595, counted 241668641
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
7ff4a425e700: Badness in key lookup (length)
bp=(bno 126400, len 16384 bytes) key=(bno 126400, len 8192 bytes)
- agno = 1
- agno = 2
- agno = 3
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 2
- agno = 3
- agno = 0
- agno = 1
Phase 5 - rebuild AG headers and trees...
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
disconnected inode 252816, moving to lost+found
Phase 7 - verify and correct link counts...
done
[root@pc4 ~]#
[root@pc4 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 194G 5.2G 179G 3% /
tmpfs 63G 72K 63G 1% /dev/shm
/dev/sda2 194M 32M 152M 18% /boot
/dev/sda4 20G 196M 19G 2% /tmp
/dev/vgca0 2.1T 1.2T 938G 55% /data1
[root@pc4 ~]# mount /data2