西部数据的SMR光盘不适用于ZFS，但适用于大多数场合。

虽然我们的延迟测试显示了WD Red eFax的固件可能存在的问题，但显示的严重故障相对来说是转瞬即逝的。在很大程度上，Red的固件很好地处理了我们对消费类硬盘所期望的所有用例工作负载。尽管如此，我们还是想知道为什么当被要求在ZFS下处理类似的任务时，它会失败得如此惨烈。

为此，您需要了解ZFS--尤其是ZFS RAIDz，比如Servethehome test--实际上是如何写入数据的。当您要求mdraid RAID6阵列存储1MiB的数据块时，数据将以易于管理的512KiB区块形式存放在总共两个驱动器上。正如我们在这里的每个测试中看到的那样，Red可以(至少在大部分情况下)很好地处理该工作负载。

但是，当您将相同的数据保存到ZFS RAIDz vdev时，每个磁盘的工作负载看起来非常不同。默认ZFS记录大小为128KiB-每个完整大小的数据块在vdev的n-P个磁盘之间平均分配，其中n-P是磁盘总数，P是奇偶校验块的数量。因此，对于ServeTheHome的四磁盘RAIDz1 vdev，记录存储在每个磁盘的44KiB(128/3，向上舍入到最接近的偶数扇区大小)块中。在我们自己的八磁盘RAIDz2 vdev中，记录以24KiB(128/6，四舍五入)块存储。

现在我们了解了这一点，我们知道我们可以通过大规模顺序写入来模拟理想的ZFS重新同步工作负载-我们使用32KiB的不可压缩伪随机数据块，在我们的Ironwolf基准磁盘和WD Red 4TB eFax测试磁盘上确实做到了这一点。在此测试工作负载下，我们在Ironwolf上实现了209.3MiB/秒的吞吐量，但在Red上只有13.2MiB/秒-15.9：1的减速，这确实非常符合Serve Home在他们的ZFS Re Silver测试中观察到的15.7：1的减速。

我们要非常明确地说：我们同意希捷的格雷格·贝罗尼(Greg Belloni)的观点，他代表希捷表示，他们不建议将SMR用于NAS应用程序。在绝对最好的情况下，SMR磁盘的性能明显逊于CMR磁盘；在最坏的情况下，它们可能会非常糟糕，以至于可能被错误地检测为故障硬件。

这样说来，我们就可以理解为什么西部数据在经过我们假设的大量实验室测试之后，相信他们的磁盘对于典型的NAS使用来说是正常的。虽然明显慢于其Ironwolf竞争对手，但它们在传统RAID重建和典型的日常NAS文件共享工作负载方面都有足够的表现。

固件如何很好地适应大多数工作负载给我们留下了深刻的印象-这是RFC 1925 2的一个明显的例子。(3)它正在运行，但推力似乎确实足以达到目的。不幸的是，西部数据似乎没有测试ZFS，而ZFS是他们相当少数的客户群所依赖的。

对于目前正在进行的针对西部数据的美国或加拿大集体诉讼来说，这些测试可能都不是好消息，但它们也不是这些诉讼的终点。即使在最好的情况下，WD Red的SMR车型的表现也远远逊于早先的非SMR车型-而且消费者没有得到降级的明确通知。

如果使用相同的固件向消费者提供比其他情况下更大的驱动器，并且充分解释了这些驱动器的限制，我们可能会滔滔不绝地谈论其实用程序和功能。不幸的是，西部数据公司到目前为止只选择用它来削减小磁盘的制造成本，甚至没有将节省的成本转嫁给消费者。