叠瓦式磁记录 (SMR) 设备管理 - 顺序写入性能优化

叠瓦式磁记录 (SMR) 设备管理 - 顺序写入性能优化

最近(2020-05),许多 HDD 生产商被发现正在悄悄用 SMR 磁盘替换 CMR 线路,这让整个概念得到了更多的曝光。

似乎大多数设备管理的 SMR 磁盘首先将信息写入专用区域,然后进行后台更新以隐藏写入放大问题。如果我正在写入一个空磁盘并复制大型媒体文件(本质上是顺序写入),SMR 设备管理固件是否足够智能,可以直接写入瓦片区域,而不是将其存储在临时位置,然后将其移动到最终位置?

有什么方法可以优化写入模式吗?

附言 更新我的个人经历,这绝不是一个完整的答案。

我获得了 WDC WD60EFAX-68JH4N1 作为我桌面上的“热备份”。

  • 我将设备安装为 ext4,并且诺亚泰选项(不允许写入“最后访问”时间记录。)
    • 日志记录时间由于它开始更新目录结构上的小块(恰好位于瓦片区域上),因此会降低 SMR 性能)
  • 我使用连续随机数据对动态生成的大文件进行了写入测试。第一次运行的性能还不错。
  • 我用 rm 删除了文件
  • 迪德·弗斯特里姆
  • 并写入了巨大的充满零的文件
  • 重复刺激
  • 使用块复制复制了一个较小的磁盘,调整了分区大小以匹配磁盘,使磁盘 ID 唯一,以及一些其他文件系统维护任务,我不记得了
  • 块复制的性能很好
  • 此后,我只进行较小的增量复制,并没有遇到性能问题。

我的结论是

  • 使用 fstrim 或写入零来“擦除”/标记 SMR 区域为空闲。这样,当您“第一次”写入它们时就不会出现写入放大
  • 挂载/格式化为 ext4 等简单文件系统,并确保诺亚泰已设置
  • 初始复制是一个相当复杂的过程,但可行
  • 这是一次很好的学习经历,我变得更加聪明了:)
  • 总体而言,管理 SMR 磁盘需要付出很多努力。如果您拥有大量相对静态的数据,这种努力可能是值得的。对于家庭用户来说,价格折扣可能不值得(当然,这取决于您得到什么,但 20% 的典型成本差异对于您得到的限制来说是微不足道的,尤其是对于没有深入了解的家庭用户而言)

答案1

今天早些时候,我带着同样的问题来到这里,虽然我没有通用的答案,但我有全新的体验。

我使用具有 UAS 功能的优质 USB3/SATA 转换器盒将 ST1000LM048 外接至 PC。磁盘驱动器是当代最基本的老式旋转式锈迹斑斑的笔记本驱动器,具有 SMR 功能。实际上,我在 PC 内部的 SATA 上还有另一块相同驱动器型号。这两个驱动器的购买时间相隔约 3 年,并且都在 smartctl 中报告了 FW rev. 0001。Seagate 没有为这些驱动器提供更新。我的操作系统是 Linux,Debian 11 - 这使我能够看到一些内部情况,并且在块和 FS 层(带有 FUSE 2.9.9 的 NTFS-3G)中有一些特殊之处。总体设置和情况就这么多。

今天早上,我开始计划将外部驱动器“逐步”用作带有 USB 附件的便携式备份/传输盒。我用 NTFS 创建了一个分区,在 PC 上,我有一个目录结构,其中包含几年的照片和一些视频片段。它们都是相对较大的文件,大约 2 MB 及以上。总共略大于 50 GB。我选择了一些顶级目录,并在“文件资源管理器”(XFCE Thunar) 中开始复制。初始传输速率约为 30 MBps(PC 只有 USB 2.0)。大约 15 GB 之后,传输速率开始下降,25 GB 之后,约为 2 MBps,此时我优雅地暂停并取消复制 - 这样已复制的文件仍保留在目标位置,并且所有缓冲区都正确“同步”到盘片。然后,我开始探测小精灵可能藏身的确切位置。

Thunar 显示进度和短期平均传输速率。我还运行了“iostat 2”,并密切关注 /proc/meminfo 中的“Dirty”和“Writeback”。我将 dirty_ratio 和 dirty_background_ratio 调高到大约 80%,并尝试将 IO 调度程序 (mq_deadline) 中的 nr_requests 增加到大约 1000。此外,我还延长了写回耐心 — 如果可能的话,利用 RAM(分页)作为巨大的写回缓冲区。这可能会受到屏障操作的阻碍……无论我尝试什么,写回都从未超过大约 3 MB,而 Dirty 可能会超过 1 GB。

我事先就知道(根据自己过去的经验),如果将一些持续负载推到 NTFS 数据路径上,默认设置下的 ntfs-3g 会逐渐消耗更多的 CPU,然后吞吐量会下降。因此,我尝试做的第一件事就是卸载驱动器,然后拔下并重新插入 USB 电缆,以刷新该设备的任何 ntfs-3g 内存缓冲区。由于这并没有带来改善,我重新启动了 PC - 根据我以前的经验,这确实带来了缓解。但今天没有 - 没有改善的迹象。在我恢复复制后,传输几乎立即变得缓慢。

今天我了解到,ntfs-3g 中的这个怪癖可以得到极大缓解通过使用两个额外的挂载选项:big_writes 和 lazytime。在我今天的特定情况下,这并没有多大帮助。我确实注意到 CPU 使用率从 10% 下降到大约 1%(由 mount.ntfs-3g 消耗),因此挂载选项确实有效,但仍然新开始的传输(跟进之前复制的内容)在传输另一个 1 GB 左右后几乎立即停止,我们下降到大约 2 到 5 MBps。

我还检查了密封外壳中的磁盘驱动器是否运行过热。情况并非如此,温度没有超过 40C 左右。同时,内部驱动力约为 52-55C,而且非常幸福。

所以我最后的猜测是:瓦片。瓦片记录。如果我停止数据复制并卸载分区,磁盘活动 LED 就会乖乖变暗,但我可以听到(并在我手中感觉到)驱动器的磁头一直在晃动。显然,它是在“清洁”,将数据从 CMR 缓冲区编织到瓦片轨道中。它继续晃动磁头五分钟,所以我让它运行了一个小时,同时我去买了一些杂货。当我回来时,驱动器在旋转但安静 = 没有寻道活动。所以我恢复了复制流量......在写入大约 3-5 GB 后,我回到了大约 5 MBps。

因此,我让它多待一会儿,进行一些清洁工作,然后我又继续复制,让它一直爬到我的照片档案的最后。

我的结论是:CMR(PMR?)缓冲区只有在出厂时才会是空的。一旦您开始写入一些数据,CMR 缓冲区就会保持一定百分比的填充,这是持续写入的容量与 SMR 磁道清洁的最佳性之间的权衡。磁盘驱动器不会尝试处理来自 CMR 缓冲区的所有数据。相反,我认为磁盘推测保留最近写入的块很方便,因为它很可能可以与附近 LBA 偏移处的更多写入合并。因此,如果我没有记错的话,缓冲区将永远不会再以持续的峰值 CMR 传输速率进行最初持续的 10-15 GB 写入。(这有点像操作大型河流大坝。为了最大限度地提高水力发电量,当局喜欢保持高水位 = 让大坝几乎满负荷运行,这会妨碍大坝应对洪水事件的能力。)

此处描述的行为可能是特定廉价基本笔记本电脑磁盘驱动器的特征。针对其他用途(尤其是 NAS/RAID/企业用途)进行调整的 SMR 驱动器可能会具有更先进的算法和更精细的调整。

此外,根据“缓存”数据在 CMR 缓冲区中的存储方式,ntfs-3g 最初用不必要的小事务填充 CMR 缓冲区这一事实可能会对外部行为产生不利影响。也许如果我在出厂时使用 big_writes 和 lazytime 启动,驱动器会应对得更好。或者可能不是......我的意思是说,我怀疑我的特定 OS+FS 设置不是磁盘驱动器优化和测试的场景。

磁盘驱动器固件中似乎没有任何可配置的“旋钮”来控制瓦片清理算法。如果至少有一个 SMART 属性或类似的东西来告诉我 CMR 缓冲区的当前“填充级别”,那就太好了,我可以想象还会有其他有用的效率统计数据来说明清理算法的运行情况……但这可能要求太多了。闪存 SSD 也不提供此类数据。它可能与磁盘驱动器供应商的专有“知识产权”过于密切相关。

优化流量的唯一方法可能是调整 FS 以获得更大的“集群大小”(分配单元大小),并调整执行写入的用户空间软件以大块形式发出/提交写入。根据我的经验,这往往不是用户可配置的属性,即使在软件中这会有很大帮助。例如,Web 服务器从远程用户那里接收许多缓慢的同时上传(必须将多个慢速流存储到具有有限 IOps 功能的驱动器中)等。

相关内容