为何添加SLOG后TrueNAS的顺序同步写入性能反而下降？

这问题确实挺反直觉的——按常理SSD当SLOG应该能提升同步写性能才对，结合你给出的测试细节，我来拆解几个可能的原因：

1. SLOG单盘的持续写入瓶颈，被主vdev的多盘并行能力反超 #

你的主存储池是3个镜像vdev、共6块SATA盘，当没有SLOG时，ZFS会把ZIL（事务日志）分散到多个vdev的空闲空间进行同步写入，能充分利用多盘的并行IO带宽；而你的850 Pro虽然标称500MB/s的写入速度，但它的SLC缓存容量有限，在大文件持续同步写的场景下，缓存很快就会耗尽，后续写入会掉到SSD的原生TLC速度（通常远低于标称值），反而不如6块机械盘并行写入的总带宽，这就解释了bonnie++测试里480M/s vs 107M/s的反转。

2. 大文件同步写场景下，SLOG的两次IO开销成了累赘 #

ZFS的同步写流程在有无SLOG时差异很大：

• 有SLOG时：必须先把ZIL记录写入SLOG（等待硬件确认写入完成），再把数据块写入主池（后台异步，但大文件下ARC存不下，后台刷写会频繁触发），相当于多了一次强制同步IO的开销；
• 无SLOG时：ZFS可以把ZIL记录和数据块的写入合并到同一次IO操作里，减少了额外的IO往返次数，尤其是大文件顺序写时，这种合并优化的效果会被放大。

3. cgroup内存限制放大了SLOG的劣势 #

你用memory.limit_in_bytes=4G限制了测试进程的内存，这直接压缩了ZFS的ARC缓存空间。ARC本来是用来缓存数据、减少频繁刷盘的，当它被严重限制时，ZFS会更频繁地把数据从ARC刷写到主池，同时SLOG的ZIL写入也会被迫拆分成更多小批量提交——虽然SSD在小IO场景下有优势，但大文件持续写时，这种频繁提交会让SSD的SLC缓存更快耗尽，进一步拉低整体写入速度。

从你后续的fio测试结果也能验证这个逻辑：

• 小文件循环写（--rw=write --loop=1000 --size=8k）：SLOG的低延迟优势体现出来，速度是无SLOG的1.67倍；
• 中等文件少循环写（--rw=write --loop=10 --size=32M）：多盘并行的带宽优势超过了SLOG的低延迟，无SLOG速度反超；
• 超大文件单次写（--rw=write --loop=1 --size=1G）：两者性能接近，说明单盘SSD的极限带宽和多盘并行的带宽差不多抵消了。

备注：内容来源于stack exchange，提问作者Lukas