西部数据一直受到负面新闻的风暴——甚至是诉讼——关于他们试图将SMR磁盘技术偷偷带入他们的“红色” NAS磁盘系列。为了更好地处理这种情况，Ars 购买了西部数据 4TB Red EFAX 型号 SMR 驱动器并自行对其进行了测试。
近日，知名科技爱好者网站Servethehome 用ZFS测试了一款基于SMR的4TB红盘，发现它严重不足。该磁盘在一般性能测试中表现良好——如果表现不佳的话。但是，当 Servethehome 用它来替换降级 RAIDz1 vdev 中的磁盘时，它需要 9 天多的时间来完成操作——而所有竞争的 NAS 驱动器在大约 16 小时内执行相同的任务。
这理所当然地引发了西部数据在尝试在 NAS 驱动器中使用 SMR 技术时的想法，更不用说试图将其潜入市场了。西部数据甚至测试过这些磁盘吗?但与 Servethehome 的 ZFS 测试一样有价值，他们忽略了此类驱动器的最常见用例——消费类和小型企业 NAS 设备，例如Synology 的 DS1819+或Netgear 的 ReadyNAS RN628X00。这些都使用 Linux 内核 RAID (mdraid) 来管理他们的阵列。
重建 75% 满八盘 RAID6 阵列
在购买了 Servethehome 测试过的 WD 4TB Red EFAX 驱动器后，我们使用现有的测试设备和 Ars Storage Hot Rod中的八个 Seagate Ironwolf 驱动器来创建 RAID6 阵列。我们的八个 Ironwolf 磁盘是一块 12T，因此我们将它们分区为一块 3500GiB——这使得阵列足够小，以至于我们的新 WD Red 磁盘可以“适合”作为 Ironwolf 出现故障时的替代品。
当我们创建 RAID6 阵列时，我们使用了参数-b none，以防止它在使用以前位于阵列中的磁盘时尝试执行位图扫描以进行更快的重建。我们使用 ext4 文件系统对其进行格式化，并带有参数，-E lazy_itable_init=0,lazy_journal_init=0 以便后台进程不会因普通用户通常不会与之抗衡的驱动器活动而污染我们的测试。
格式化新的 8 个磁盘，19TiB 阵列后，我们将 14TiB 的数据转储到它的 14 个子目录中，每个子目录包含 1,024 个 1GiB 文件，其中填充了伪随机数据。这使阵列的使用率略高于 75%。此时，我们将一个 Ironwolf 磁盘从阵列wipefs -a /dev/sdl1 中取出，对其进行了删除现有 RAID 标头的操作，然后将其重新添加到现已降级的阵列中。这是我们的基线。
Ironwolf 成功重建到阵列中后，我们再次失败了——这一次，我们将它从系统中完全移除，并用我们的 4TB Red SMR 豚鼠代替。首先，我们将整个 4TB Red 馈送到降级阵列，作为丢失的分区 Ironwolf 的替代品。然后一旦它完成重建，我们再次失败，从它取出wipefs -aRAID 标头，然后重新添加它以进行第二次重建。
这给了我们两个测试用例——一个出厂新的 Red SMR 磁盘被重建到一个阵列中，一个 使用过的带有大量数据的 Red SMR 磁盘已经被重建到一个阵列中。我们认为两种方式都进行测试很重要，因为每种情况都是现实世界中 NAS 磁盘的常见用途。充满数据的 SMR 磁盘似乎也可能比全新的磁盘性能更差，因为它处理已使用的区域时不需要读取-修改-写入。
我们对 SMR 磁盘在第一次测试中表现良好并不感到惊讶——除了消费者的愤怒之外，Western Digital 似乎不太可能在没有任何测试的情况下将这些磁盘发送出去。更令我们惊讶的是，它在使用过的条件下的表现与新的一样——驱动器的固件能够很好地随机播放数据，以至于从“使用过的”条件中重建不需要额外的一分钟它有新的时候。
简单的 1MiB 随机写入测试
很明显，WD Red 的固件能够应对处理传统 RAID 重建的挑战，这相当于一个巨大的、非常大的块顺序写入测试。接下来要检查的是 EFAX 是否能够很好地处理消费者 NAS 的典型日常用例的繁重版本——即存储大文件。
再一次，乍一看，WD Red 通过了集合。在吞吐量方面，Red 仅比其非 SMR Ironwolf 竞争对手慢 16.7%。即使是第二次重新测试，当固件处理已经满的区域的工作更难时，也不会显着改变图片。
当我们深入一点并查看fio延迟数字时，情况看起来明显更糟。EFAX Red 从手术中返回的平均速度比 Ironwolf 慢 68.8%——但同样，这是“没有赢得比赛”的领域，而不是“你会因欺诈而被起诉”的领域。只有当我们查看 1MiB 随机写入测试的峰值延迟时，我们才开始看到当您将 Red 推向计划外的方向时，事情会变得多么糟糕。其最坏情况下的返回时间高达 1.3 秒，比 Ironwolf 最慢的 108 毫秒返回时间差十多倍。
我们可以从这个峰值延迟结果推断，当 Red 的固件严重挣扎时，其吞吐量可能会在一段时间内低于 1MiB/秒——这与我们在观察吞吐量测试运行时看到的不断变化的吞吐量数字相关。它还告诉我们，对于桌面用户，他们希望 在单击按钮和拖动东西时发生事情，Red 偶尔会在本应非常非常轻松的工作负载中提供真正令人沮丧的体验，即使对于传统驱动器也是如此.