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

现象

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

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

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

log中报错信息为：

could not flush dirty data: Cannot allocate memory

排查

再看操作系统内存，发现还有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命令，可以阅读描述：

常用选项和注意事项