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

原文：https://bbs.huaweicloud.com/blogs/174945

现象

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

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

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

2. log中报错信息为：

could not flush dirty data: Cannot allocate memory< /span >< /code >

 

排查

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

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

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

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

   

    

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

   

修复EXT4文件系统

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

1. 使用root用户登录系统

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

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

fuser -mv /dev/sdh1

1.  

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

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

1.  

2. 卸载磁盘

 

umount /dev/sdh1

1. 使用fsck工具修复系统

1. 运行命令并确认

fsck.ext4  /dev/sdh1

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

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

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

            

 

1.     通过reboot重启系统，修复工作结束。

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

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

 

1. 常用选项和注意事项