这边更新一下处理结果，回去之后在 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 反而是最容易出问题的

目前用下来还是 NASTOOL 最合适，其实就自动刮削识别度来说 NASTOOL 没比 TMM 好多少，NASTOOL 主要是支持硬链接，硬链接过去的文件名很规范，然后硬链接也可以解决保种的问题，很适合各种其他应用去读取使用(jellyfin/plex/kodi)等

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

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

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

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

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

可以蹲个二手 RB5009 好价或者 mikrotik （ bugtik ）其他类似的产品，有一说一，从 7.4 开始说支持容器之后（一大堆 bug ），修修补补大半年，目前 7.9 stable 的 container 总算是勉强能正常使用了，等出个 7.X 的 LTS 就可以养老了

unraid 我觉得可以...适应了以后没那么难用

hyper-V 我个人觉得很难用....使用体验还不如 virtual box ，特别是 hyper-V 的网络部分，体验相当的糟糕..尝试了几次就放弃了，可能因为用的不是 windows server 平台吧....当然纯个人体验.....

如果单纯为了翻梯子我倒觉得不需要单独购置一个软路由，all in one 附带一个就行
老家的话...强烈推荐 NAS 设备带 IPMI 的，然后 UPS 啥的都要配置好...然后还能叫到人能进行设备的简单关闭重启...不带 IPMI 就放弃吧，出了问题你难受死

all in boom 了，虚拟化底层可以考虑 PVE 或者 unraid ，我个人是 12400 平台 PVE 做底层，把阵列卡直通给 unraid ，同时把核显 sr-iov 虚拟化给 windows ，平时就靠串流远程访问 windows 玩小游戏（舰 C 和 FGO ），个人觉得 NAS 平台的功耗还是主要看机械硬盘数和暴力扇的个数，只要你不是上什么 E5 洋垃圾之类的，近几年桌面级 CPU 功耗控制其实都还可以