米鼠商城

多快好省,买软件就上米鼠网

最新项目

人才服务

靠谱的IT人才垂直招聘平台

RHEL8.2-虚拟机异常断电导致Structure needs cleaning.问题

  • xuxiang
  • 7
  • 2020-11-21 23:15

RHEL8.2-虚拟机异常断电导致Structure needs cleaning.问题

[root@esdb02 ~]# xfs_repair -L /dev/mapper/vgesdb-lvesdb 

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...

sb_icount 3712, counted 4160

sb_ifree 376, counted 296

sb_fdblocks 20768280, counted 20642135

        - 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

data fork in ino 67445213 claims free block 8430646

data fork in ino 67445213 claims free block 8430647

data fork in ino 67445220 claims free block 8430656

data fork in ino 67445220 claims free block 8430657

correcting imap

correcting imap

correcting imap

correcting imap

correcting imap

correcting imap

data fork in ino 67446858 claims free block 8430876

data fork in ino 67446858 claims free block 8430877

data fork in ino 67446874 claims free block 8430855

data fork in ino 67446875 claims free block 8430854

data fork in ino 67446880 claims free block 8430864

data fork in ino 67446881 claims free block 8430865

data fork in ino 67451841 claims free block 8431479

data fork in ino 67451842 claims free block 8431478

data fork in ino 67451843 claims free block 8431488

data fork in ino 67451846 claims free block 8431491

data fork in ino 67451847 claims free block 8431489

data fork in ino 67451848 claims free block 8431492

        - 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 = 0

        - agno = 1

        - agno = 2

        - agno = 3

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 ...

Phase 7 - verify and correct link counts...

Maximum metadata LSN (15:40496) is ahead of log (1:2).

Format log to cycle 18.

done

[root@esdb02 ~]# 

[root@esdb02 ~]# mount -a

[root@esdb02 ~]# 

[root@esdb02 ~]# df -h

Filesystem                 Size  Used Avail Use% Mounted on

devtmpfs                   1.5G     0  1.5G   0% /dev

tmpfs                      1.5G  8.7M  1.5G   1% /run

tmpfs                      1.5G     0  1.5G   0% /sys/fs/cgroup

/dev/mapper/vgroot-lvroot   10G  9.3G  756M  93% /

tmpfs                      297M     0  297M   0% /run/user/0

/dev/nvme0n1p1            1014M  160M  855M  16% /boot

/dev/mapper/vgesdb-lvesdb   81G  2.9G   79G   4% /esdb

[root@esdb02 ~]# 

========================================================

参考文献

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/usbmount /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



这里给大家推荐一个在线软件复杂项交易平台:米鼠网 https://www.misuland.com

米鼠网自成立以来一直专注于从事软件项目人才招聘软件商城等,始终秉承“专业的服务,易用的产品”的经营理念,以“提供高品质的服务、满足客户的需求、携手共创双赢”为企业目标,为中国境内企业提供国际化、专业化、个性化、的软件项目解决方案,我司拥有一流的项目经理团队,具备过硬的软件项目设计和实施能力,为全国不同行业客户提供优质的产品和服务,得到了客户的广泛赞誉。



如有侵权请联系邮箱(service@misuland.com)

猜你喜欢

评论留言