去年1月，一位做存储的博主在知乎发了一篇长文，标题直接就是情绪：「装了一个TrueNAS，很失望。24盘ZFS RAIDZ2，25g网卡直连拷贝速度拉胯」。知乎这不是普通吐槽帖——他给出的测试环境堪称教科书级别，评论区452条，吵到今天还不断被新帖引用。
为什么这篇帖子值得翻出来再看一遍？因为过去大半年，TrueNAS圈子里的速度焦虑一直在发酵：6月有用户发帖盘点自己几年间遇到的truenas/zfs各种崩溃。知乎至今还有人在问「24块盘到底该组ZFS还是硬RAID60」。一边是「企业级、免费、ZFS数据安全」的口碑，一边是「越盘多越慢」的实测，中间差的不是立场，是一条没人讲清楚的写入链路。
先看配置：这台机器挑不出硬件毛病
先说清楚原帖的测试环境，这是它能吵起来的前提。知乎
服务器：C612平台，双路E5-2667v4，16×8G共128G REG ECC DDR4，1300W电源
存储：24块HGST 3T SAS机械盘（7200转），原生24口LSI SAS 3224直通卡+24口直通背板，规避了扩展卡带宽瓶颈
网络：迈洛思4421a双口25G网卡，客户端同为25G网卡，光纤直连
系统：TrueNAS 24.10.1，24盘组单个RAIDZ2，去重、快照全关
而且作者事先在Windows下把24块盘同时检测了一遍：单盘约160MB/s，总带宽接近4GB/s，直通卡到硬盘链路没有问题。
结果呢？拷一个10G大文件，起步600MB/s，很快掉到200-300MB/s波动；拷70G文件，起步660MB/s，随后掉到200MB/s。后台显示同步到每块机械盘的写入最快只有37MB/s。作者加了两块1.6T的NVMe做log盘和缓存盘，起步能到1.5GB/s，但坚持不了5秒又掉回300多。
帖子下面第一条高赞反驳是「你这大概率是CPU和内存瓶颈」，作者直接甩出功耗和占用数据回怼：写入时整机功耗380W和待机几乎没区别，CPU占用常年在10%左右，「两个E5-2667v4加128G内存成为24盘机械阵列的瓶颈，我牙都笑掉了」。这条互怼楼中楼盖了82层。
第二组独立实测：60盘一样快不起来
如果只有一个案例，还能说是个例。2025年3月，另一位用户在60盘位服务器上做了对照实验。知乎
双路Intel金牌6142（32核64线程）、11条32G内存、60块18T硬盘、25G网卡、LSI 9300-8i
TrueNAS组RAIDZ2，加两块7.68T U.2做缓存
结果：RSYNC多线程总带宽不超过500MB/s，单线程200-300MB/s
最有意思的是后半段：他把同一台机器换成黑群晖SA6400，组RAID6（14+2），大文件拷贝轻松超过1GB/s——但小文件依然在300MB/s左右，他归因于IOPS不足。知乎
两组独立实测指向同一个模式：大容量机械阵列在TrueNAS上的写入，普遍卡在200-500MB/s；小文件场景大家都停在300MB/s上下。这已经不是「会不会调」的问题，而是某种机制在起作用。
评论区的四个流派，逐一说清楚
原帖评论区452条，观点高度集中，大致可以分成四派。把每派的依据摆出来，对错其实能判断大半。
流派一：硬件瓶颈派——证据最弱。 认为CPU或内存不够。但两位实测者都给了反证：CPU占用个位数、功耗不涨、128G内存远未吃满。ZFS的校验计算确实吃CPU，但24块7200转机械盘的吞吐，远没到双路E5的极限。这一派基本可以排除。
流派二：调优派——说对了一半。 有人说「自己不会调优，别赖ZFS」，并举出36盘调出读7GB/s、写5GB+/s的例子；也有6块SAS盘组RAIDZ1随便跑900多兆的反例。调优确实有用，原文作者自己就验证了最关键的一条：把recordsize从默认的128K调到1M/2M，大文件速度从200多直接稳定在780MB/s。知乎但注意，调完也只到780，且3-10MB的MP3小文件依然只有300。调优能救回一部分，救不回全部。
流派三：协议与网络派——有实锤但权重小。 评论区有用户指出：TrueNAS 24的SMB和NFS都无法开启RDMA，要到25企业版NFS才支持，而Windows存储池默认就开RDMA。知乎对追求25G跑满的极端场景，这是真实短板；但对200-300这个量级的落差，它解释不了大头。
流派四：机制派——最接近本质。 评论区有位用户的解释被反复引用：TrueNAS写入类似「泳池放水注水」，ARC内存先缓冲写入，异步模式下约每5秒一次交易组（txg）落盘，客户端看到「传输完成」时，数据其实还在从内存往机械盘搬。知乎这直接解释了两件事：为什么起步能跑600-660（那是写进内存的速度），为什么随后掉到200多（那是24块盘真实的同步写入速度）。
还有一位用户提到自己遇到几乎一样的问题，最后发现是HBA直通卡过热。知乎这提醒一句：复现「慢」之前，先排除散热这类低级但真实的坑。
为什么NVMe缓存没用？先搞懂SLOG和L2ARC
原帖作者最困惑的一点：加了两块NVMe，速度几乎没变化。评论区的解释其实很明确：
L2ARC是读缓存，对写入没有加速作用；
SLOG（ZIL）只服务同步写入——正常运行的系统里ZIL永远只写不读，它的作用是在断电、崩溃时重放还没落盘的事务。日常SMB拷贝走的是异步写，SLOG自然帮不上忙。知乎
所以「NAS加块固态做缓存就快了」这个直觉，在ZFS这里要打个问号：你得先确认自己的场景是不是同步写（数据库、虚拟机磁盘、NFS sync导出是；日常拷电影不是）。
顺带说清一个容易混淆的点：ZFS的内存ARC倒是真的在充当写缓冲——这正是「起步快、后面掉速」的来源，也是断电丢数据窗口的来源。用异步写换速度，就得配UPS，这在评论区基本是共识。
继续用TrueNAS，这五件事值得做
把整场论战里有实锤的部分沉淀下来，对打算组多盘位机器的人，可以浓缩成一张清单：
先按场景选阵列形态。4-8块盘优先镜像或小RAIDZ1，甚至多个vdev条带；一上来就组12盘、24盘的宽RAIDZ2，写入性能对recordsize和文件形态极其敏感。
大文件仓库，recordsize直接给到1M。这是原帖实测验证过的最有效单项调整，从200多拉回780。代价是对小文件不友好，所以按数据集分开设置，别图省事全局一刀切。
别盲买SLOG。日常SMB拷贝加SLOG基本无感；确认真有同步写需求再上，并且优先选掉电保护的盘。预算有限时，把SSD花在metadata special vdev上，对大量小文件的体验改善更直接——评论区有用户正是靠这个配置反超了原帖环境。
接受「进度条骗你」这件事。ZFS异步写模式下，客户端传完不等于落盘完成。在意数据安全，就配UPS并理解这个窗口；完全不能接受，就用同步写+UPS的代价换确定性。
小文件密集场景（海量照片、文档库），多盘RAIDZ不是好选择。两组独立实测的小文件都停在300上下，瓶颈在元数据和随机写，堆盘数和内存都救不了。这类需求要么换阵列形态，要么干脆重新评估系统选型——这也是为什么越来越多人把「存相册」这类任务交给别的方案。
争议之后：两个大版本补的正是这些课
还有一个值得关注的后续：这场论战之后，官方有没有动作？看TrueNAS在2025年发布的两个大版本，不少更新条目正好对着评论区的痛点来的：
25.04「Fangtooth」（2025年4月发布）：结束CORE与SCALE并存的局面，统一运行在Linux内核6.12上，带来超过1000项更新。与这场争议直接相关的是，iSCSI和NFS获得RDMA支持，补上了流派三吐槽的短板，RAID-Z扩容也大幅提速，多盘阵列扩容不再必须推倒重建。网易
25.10「Goldeye」（2025年10月发布）：ZFS获得Direct I/O支持、内存压力处理优化、I/O扩展性增强，虚拟机内存管理更新还解决了ZFS ARC冲突导致的内存溢出问题。网易
但要冷静评估：这些更新补的主要是协议短板和平台级问题。宽RAIDZ2机械阵列在物理层面的写入天花板，不会因为版本更新被推翻——流派四的机制判断，在新版本里依然成立。
这场论战真正说明的事
回到标题里的问题：24盘只有200MB/s，是TrueNAS的耻辱吗？
把证据摆完，答案没那么简单。可以确定的结论只有三条：多盘宽RAIDZ2的写入速度，在默认设置下显著低于大多数人的预期；recordsize等调优能拉回一大截但拉不到理论值；SMB异步写+内存缓冲的机制，决定了「起步快、后段回落」是常态而非故障。至于「这是ZFS的原罪还是TrueNAS实现的锅」，连同一台机器上群晖更快的对照都给不出终审——两边用的文件系统和阵列实现完全不同，这更像一道调优深度和产品取向的综合题，而不是非黑即白的站队题。
对普通用户来说，值得带走的判断是：TrueNAS给你的安全下限（校验、快照、数据完整性）是真材实料，但它的速度是需要你用场景匹配和调优去换的，不是装完就送的。想清楚自己存什么、怎么存，再决定给ZFS多少期待——这比在评论区站队有用得多。
