EXT4文件系统损坏导致的实例无法启动的排查与修复

网友投稿 2075 2022-05-28

现象

某现网局点进行POC时,发现某DN core掉,且一直无法启动。

core文件堆栈和dn的pg_log日志中的堆栈信息一致。

堆栈中显示 checkpoint 时进行 buffer 落盘时导致core

log中报错信息为:

could not flush dirty data: Cannot allocate memory

排查

EXT4文件系统损坏导致的实例无法启动的排查与修复

再看操作系统内存,发现还有100G以上空闲,不存在内存不足的可能性。基本排除是因为内存导致的问题。

通过代码排查发现是调用系统函数:sync_file_range ()。但是刷盘函数一般也不会导致无法申请内存。

PS:此函数是Linux 2.6.17之后提供的用于提高IO性能的刷盘函数,作用类似于fsync等。

既然翻车在文件操作函数,可以合理怀疑文件是不是有问题。翻一下操作系统日志 /var/log/messages,发现疑点:

网上查询错误信息,基本上确认为EXT4文件系统损坏,需要对文件系统进行修复

修复EXT4文件系统

修复EXT4文件系统需要使用fsck.ext4命令,与windows的chkdsk命令一样,fsck命令是linux下必不可少的文件系统修复工具。一般都会默认安装的。

使用root用户登录系统

把要修复的磁盘umount掉。使用fsck修复文件系统一定要先把对应的磁盘卸载,否则是非常危险的(这是不如windows的地方)。

首先检查是否有其他进程使用磁盘(也可以使用 lsof /dev/sdh1 查看占用情况)

fuser -mv /dev/sdh1

杀死占用的进程,并确保没有进程占用磁盘(也可以使用 kill 杀掉对应进程)

fuser -kv /dev/sdh1 fuser -mv /dev/sdh1

卸载磁盘

umount /dev/sdh1

使用fsck工具修复系统

运行命令并确认

fsck.ext4 /dev/sdh1

运行过程中会提示 inode 的一些信息,确认即可。

如果不想要点很多次的确认信息,可以加上 -a 参数。

修复完成后,会得到如下提示,表示fs已经修复完成。

通过reboot重启系统,修复工作结束。

附:fsck命令常用选项及注意事项

fsck.ext4的manpage直接跳转到e2fsck,因为他直接调用的e2fsck命令,可以阅读描述:

常用选项和注意事项

任务调度

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:股市学习稳扎稳打(八)认识暗盘交易
下一篇:Linux常用命令大全
相关文章