求救 PVE ZFS 概率出现崩溃

[qpwo005451mark2]

机器是自己组的 ALL IN BOOM ，平台是 I5 12400+B660 ，目前在家里，平常在同城异地上班

PVE 系统采用 ZFS mirror 安装在两块致钛的 SATA 固态上（安装于主板自带的 SATA 控制器），大部分 VM 的系统盘安装在 SATA 上，NAS 系统选用的是 unraid ，阵列卡和 2 块 NVME 固态直通给了 unraid 。

PVE 的 VM 和 LXC 容器提供服务，unraid （ unraid 上自己也跑了一些 docker ）通过 NFS/SMB 方式对一些服务提供存储

其中一台 VM 运行的是 windows11 ，核显 SR-IOV 直通给 win11 虚拟机上班的时候通过远程串流玩玩舰娘+安卓模拟器，24h 运行，目前问题是最近 PVE 的 ZFS 文件系统有概率崩溃（多次和 win11 这台虚拟机里的读写操作有关，比如启动 win11 里的安卓模拟器，但是故障没法稳定复现），具体情况是 CPU 占用率低，但是 DISK IO 、IO wait 、服务器负载巨高，所有 VM 和 LXC 容器只要是在 zpool 上的基本失去响应。看起来就像 SATA 控制器被占满了一样，iosata 结果也是这样，但是 htop/iotop 在后台看不到任何读高写的进程，并且情况会逐渐恶化，最后就是 PVE 控制台也崩溃，SSH 可以进去但是运行 htop 后也不会有响应，严重到最后甚至 SSH 也无法远程登录，一般我在 ssh 还能登录的时候就选择把 unraid 数据保存以后 reboot 之后服务会恢复正常。

zpool 看起来也没问题，两块致钛的 SATA 固态 smart 也没问题，这属于 PVE ZFS 的 BUG 吗？

因为目前人在异地，周末才能回去，基本属于 all in boom 的状态了，但是 unraid 因为是 U 盘直通的系统，PVE 控制台崩溃了也不受影响，还能正常运行，今天又复现了这个问题，目前在 PVE 控制台崩溃前把 win11 VM 磁盘转移到了 unraid 直通的两块 NVME 上，目前和 unraid 一样可以正常运行。
https://upload.cc/i1/2023/05/30/vVfmaI.png
https://upload.cc/i1/2023/05/30/sfr6Bn.png
https://upload.cc/i1/2023/05/30/wF95ZD.png
https://upload.cc/i1/2023/05/30/1ViGXY.png
https://upload.cc/i1/2023/05/30/s2KlHD.png

[happyn]

我也碰过类似的问题，当时的环境是:
PVE7.1
内核:5.13.19-6-pve
zfs-2.1.6-pve1
zfs-kmod-2.1.4-pve1

三块日立 12T 做了 RaidZ1 ；刚开始用的一切都好，但是就过了一个来月，发现跟老哥一样的问题；中间各种排查各种折腾，把 zfs 的手册翻了一个遍；最后发现神奇的是电源问题，只要 IO 一上来，电源就有一个峰值，散热不好风扇呼呼吹；

后来换了个电源可以了.....

[happyn]

老哥回去以后可以注意一下电源输出，没有仪器的话可以人肉看看电源风扇；

我的环境当时表现是硬盘咔咔响，比常见的炒豆子声还要大好多，电源风扇直接起飞；

这个时候 zpool 的性能惨不忍睹，拷贝文件都 <10MB/s 了...，iostat 看占用都 100%;

不过神奇的是，同样的电源，我换了 PVE 默认的 LVM thinpool 卷管理之后，就一点问题都没有了；

[qpwo005451mark2]

@happyn 有可能，电源是机箱自带的服务器单电 1200w （二手不知道工况），两块 sata 都是从机箱里给的大 4pin 取电的，用的一分二的供电线，看来线或者电源都可能有问题？不过之前其实也稳定运行了 60 几天了，然后接入了后背式 ups ，机箱不太想换了，感觉只能放弃 pve 使用 zfs 了

[qpwo005451mark2]

@happyn 感谢了，之前没有考虑过这方面的可能性，回去排插了，看来捡垃圾中奖了

[dode]

支持限制 win11 硬盘 IO 吗

[sNullp]

另外如果开了 dedup 且内存不够也会这样

[busier]

虽然没踩这个坑，但是也刚换了电源，原因是最近总出现硬盘开机不识别，插拔线折腾下又好了，偶尔硬盘还哒哒响，C5C6 错误数上涨，硬盘经常被 Linux 给 remount 成 ro 。一顿排查就是电源毛病！

[qpwo005451mark2]

@sNullp PVE 的 ZFS pool 默认是不开 dedup 的吧，内存不够确实会这样，我刚开始折腾才发现 PVE 的 ZFS 非常坑，默认 L2 ARC 设置的是一半内存，开 VM 直通硬件就容易出现过内存不够机器跑 4-5 天固定直接 ZFS 直接卡死，后面限制过了使用 4G ，就稳定了好久，然后最近又莫名其妙发病了。

[qpwo005451mark2]

@dode 但是不可避免的总会进行读写，windows 使用还是比较频繁的，安卓模拟器使用总会进行大量的读写。目前决定 win11 存储由 unraid 来提供，zpool 尽量不去碰了。

[anguliuyun]

问题类似：

[anguliuyun]

@anguliuyun

pve-manager/7.3-3/c3928077 (running kernel: 5.15.74-1-pve)

两块希捷库狼的 zmirror, 不过我只用他做存储服务， 还有两块 m2 固态做系统盘。
IO 上来的时候会有一块硬盘断掉，内核报错 ata offline ， 不知是不是上面提到的电源问题

[anguliuyun]

@qpwo005451mark2 问下 OP 你的核显直通 win11 有 hdmi 输出吗， 我的 10 代 i5 核显 UHD630 能直通到 win11 ，正常安装驱动以及核显加速能生效， 但是 hdmi 无信号。

[qpwo005451mark2]

@anguliuyun hdmi 输出不好意思不太清楚，因为我是 12 代使用的是 SR-IOV 虚拟化，是没有 HDMI 输出的，所以我是通过 parsec/moon light 这种串流的形式远程使用，因为我确实也不需要 hdmi 输出所以没有特地研究过

[sNullp]

@qpwo005451mark2 默认是不开 dedup 的，但也可以看一下。我感觉 l2 arc 的内存很容易 evict 掉其实不怎么影响系统，但是 dedup 吃不够内存就巨卡。

[zx900930]

FS readonly 还有一个可能是 RAM 问题
你可以去下一个 memtest86+的 iso, 让你的虚拟机从 iso 启动跑一个 pass 就差不多知道 RAM 有没有问题了.

我最近出现的也是随机 crash.... 最后发现是 我的 4x16G 内存条跑 memtest86+会 failed.
但是实际上 RAM 并没有物理损坏, 而是因为 intel 12 代不带 k 的 cpu 锁了内存控制器电压, 导致 4 根 RAM 插满开 xmp 的时候, 偶尔电压不够导致内存工作异常得完全断电重启 PVE......

[anguliuyun]

@qpwo005451mark2 感谢回复，串流确实可以使用，我是因为核显的串流性能差所以想试试 hdmi 直接显示这种方式。

[qpwo005451mark2]

这边更新一下处理结果，回去之后在 ssh shell 中使用 reboot 无法关机，使用 reboot -nf 强制重启后无法重启系统，因为是 all in boom 机器，接上显示器后显示系统启动卡在 zfs 文件系统 rpool 加载的过程中，内核识别到了 rpool 并且进行加载，出现了一连串错误没有办法继续下去，每个 40s 刷新一下进度但是报错依旧，基本就是卡在系统的启动阶段，随将 PVE 系统更换为传统的 LVM 逻辑区的安装方式，导入 U 盘引导的 unraid 存储底层虚拟机后再重新将各虚拟机的备份导入，到目前为止系统稳定没有出现报错，后续继续观察是否会有类似故障出现

另外我只能分析出是某些原因导致（不清楚是硬件 /软件 /不过可以确定和 ZFS 有关）原因导致的系统日志进程报错，并且产生了大量 systemd-journald.service 子进程，HTOP 中看为上千个左右，并且为表示进程状态为 "Disk Sleep"，大量 systemd-journald.service 进程造成了 DISK IO 出现无读写无负载但是 IO some 和 IO Full 100%卡死的状态，只是不知道这是原因还是硬件报错以后造成的后果

PVE 系统日志报错情况，显示 systemd-journald.service: Watchdog timeout 看门狗超时
Jun 05 06:37:11 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
Jun 05 07:18:01 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
Jun 05 07:47:11 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
Jun 05 08:17:51 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
Jun 05 08:48:01 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
Jun 05 09:17:11 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
Jun 05 09:47:51 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
Jun 05 10:18:01 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
很多都是一样的....

systemctl status systemd-journald.service 结果
● systemd-journald.service - Journal Service
Loaded: loaded (/lib/systemd/system/systemd-journald.service; static)
Active: deactivating (final-sigterm) (Result: timeout) since Mon 2023-06-05 20:47:11 CST; 3 days ago
TriggeredBy: ● systemd-journald-dev-log.socket
● systemd-journald.socket
● systemd-journald-audit.socket
Docs: man:systemd-journald.service(8)
man:journald.conf(5)
Main PID: 774005 (systemd-journal)
Tasks: 673 (limit: 76751)
Memory: 750.2M
CPU: 17ms
CGroup: /system.slice/systemd-journald.service
├─595309 /lib/systemd/systemd-journald
├─623455 /lib/systemd/systemd-journald
├─630728 /lib/systemd/systemd-journald
├─638521 /lib/systemd/systemd-journald
├─646418 /lib/systemd/systemd-journald
├─653880 /lib/systemd/systemd-journald
├─660401 /lib/systemd/systemd-journald
├─665886 /lib/systemd/systemd-journald
├─671968 /lib/systemd/systemd-journald
├─676206 /lib/systemd/systemd-journald
├─678308 /lib/systemd/systemd-journald
├─680379 /lib/systemd/systemd-journald
├─682449 /lib/systemd/systemd-journald
├─684574 /lib/systemd/systemd-journald
├─686661 /lib/systemd/systemd-journald
├─688812 /lib/systemd/systemd-journald
├─690917 /lib/systemd/systemd-journald
├─693026 /lib/systemd/systemd-journald
├─695087 /lib/systemd/systemd-journald
├─697191 /lib/systemd/systemd-journald
├─699286 /lib/systemd/systemd-journald
├─701796 /lib/systemd/systemd-journald
非常长下面全是 /lib/systemd/systemd-journald 子进程

重装前顺便跑了 memtest ，没有跑了一晚上没有发现问题...所以目前只能怀疑 ZFS 加我的硬件造成了系统崩溃，因为已经不使用 ZFS.加上本人也不是 linux 专业，所以也无法深究原因了。
系统备份方面最后也还是使用了传统的 dd 备份整个分区到另一硬盘的方式，并且目前个人感觉家用环境 PVE 宿主机系统备份意义貌似也不是很大，因为也不需要严格保证服务不中断，把所有的虚拟机进行备份之后即使宿主机系统出现故障，重装 PVE 后把所有的虚拟机通过之前的备份就可以快速导入。所以之前 pve 系统安装时使用 zfs mirror 仅仅是看起来很美好，最后发现 zpool 反而是最容易出问题的