问题描述
我有一个运行 Debian Buster 的小型家用服务器，我有一个带 RAID 的 ZFS 文件系统 (ZFS: Loaded module v0.7.12-2+deb10u2,ZFS pool version 5000,ZFS filesystem version 5)。
由于服务器有时几天不使用，我配置了一个自动关闭脚本，如果我的 2 个大 WD 红色硬盘处于待机状态超过 45 分钟（不是系统硬盘），它会关闭服务器。现在我发现服务器不再关闭，因为两个驱动器都只有几分钟的待机状态，然后才能再次活动。我使用 iotop 进行了测试，发现使用命令 txg_sync 的 ZFS 正在唤醒它们。即使没有其他进程在驱动器上写入或读取任何内容。
在更改到数据池的挂载目录后，我还对 fatrace -c 进行了检查。当命令 txg_sync 弹出并唤醒驱动器时，此时没有输出。更新：似乎 fatrace 在 ZFS 中无法正常工作。
我现在使用 iosnoopfrom 并且现在知道 dm_crypt 定期在我的磁盘上写入。我的底层驱动器使用 LUKS 加密。
./iosnoop -d 8,16
Tracing block I/O. Ctrl-C to end.
COMM PID TYPE DEV BLOCK BYTES LATms
dmcrypt_writ 1895 W 8,16 2080476248 4096 6516.10
dmcrypt_writ 1895 W 8,16 3334728264 4096 6516.14
dmcrypt_writ 1895 W 8,16 2080429048 16384 0.16
dmcrypt_writ 1895 W 8,16 3334728272 20480 0.21
dmcrypt_writ 1895 W 8,16 2080476256 20480 0.16
dmcrypt_writ 1895 W 8,16 3328225336 16384 0.20
这是什么原因，我该如何防止这种情况发生？
解决方法
https://github.com/openzfs/zfs/issues/8537#issuecomment-477361010
@niksfirefly 如果正在写入池，那么您应该会看到 txg_sync 线程消耗的 cpu 和 I/O。多少取决于您的特定硬件、池配置、启用的功能/属性以及您的工作负载。对于您的情况，这可能是正常的。
也许这个链接也有帮助： https://serverfault.com/questions/661336/slow-performance-due-to-txg-sync-for-zfs-0-6-3-on-ubuntu-14-04
如何检查每个进程的磁盘 I/O 利用率：
cut -d" " -f 1,2,42 /proc/*/stat | sort -n -k +3
这些字段是 PID、命令和累积 IO 等待滴答。这将显示您的热进程，但前提是它们仍在运行。 （您可能想忽略文件系统日志线程。）
（来自https://serverfault.com/a/466342/580935）
,关于 ZFS 的另一个说明。 我使用的是内核 5.4 的 Manjaro 20210101，过去几周 txg_sync 的负载很高。
根据/var/log/pacman.log
[2020-12-31T08:58:24+0100] [ALPM] 升级 zfs-utils (0.8.5-2 -> 2.0.0-2) [2020-12-31T08:58:24+0100] [ALPM] 升级 linux54-zfs (0.8.5-10 -> 2.0.0-6)
从那时起，txg_sync 进程也恢复了平静。
在 Debian 下，ZFS（及其版本）的使用肯定会有所不同。