请教大家一下生产环境 Linux 服务器文件系统的一些问题

[zhoudaiyu]

我们的系统盘是 xfs （红帽 7 的操作系统），数据盘 ext4 ，但是昨天机器突然所有进程都 hung 了，CPU 使用率从 40 多降低到了个位数，进程状态基本都为 D ，负载从几十到了 20000 多，系统日志显示 jbd2 卡了 120s ，其他进程也有卡主 120s 的(Flink on K8s)。机器 reboot 之后恢复了，现在怀疑是内核的 ext4 文件系统有问题，但是也不能 100%确定。从我的角度上考虑，可以将 ext4 换成 xfs 去规避问题。请大家给个建议吧，目前看只能长时间用红帽 7 了，内核就到 3.10.1160 了。

[zhoudaiyu]

@msg7086 #17 oracle 的，看上去可能稳定一些，我调研一下

[blackeeper]

可能是内存条故障了，你可以 cp 一个大文件，大于内存容量的文件，看看系统是否 hung 住了
我以前有两条内存条，跟你状况一样，文件系统也是 xfs ，运行一段时间也是突然所有进程都 hung 住了，shell 有些命令可以执行，磁盘不能写，以为是文件系统或者磁盘故障，最后排查下来发现是其中一条内存条故障了。

[mdeche101644]

mark 一下看后面有没有大佬给解释一下。应该产生 coredump 了吧，可能需要分析那个，看看哪个进程或行为导致日志的 dirtynode 了。日志里是不是在说 dcgm 删某个节点了，然后是不是删了又执行某些操作出问题了，请大佬们指正

[zhoudaiyu]

@blackeeper 试了这个倒是没事儿
@mdeche101644 没有产生，只有内核崩了才有我记得

[Emiya1208]

0.1 硬盘坏了可以在 dmesg 里面看到
0.2 内存可能需要添加 mcelog 监控，可能内存坏了。

上面是回复前几楼的猜想。

实际上应该还是内核的 bug 。

1. 红帽的回答已经很清楚了，并给出来了诊断步骤。可以用诊断步骤确认。

2. 由于 JBD2 的锁机制和同步方式在某些情况下可能导致死锁问题，xfs 不使用 JBD2 ，更换 XFS 很可能解决问题。

3. jbd2 日志线程在等待获取 j_checkpoint_mutex 锁。j_checkpoint_mutex 锁当前由某个任务（例如 java 进程）持有。
持有锁的任务正在等待 j_wait_done_commit 队列唤醒，而 j_wait_done_commit 队列需要 j_checkpoint_mutex 锁来继续，这形成了一个死锁。