我想用企业级 SSD 升级现有存储子系统。但是，我几乎没有发现关于附件缓存应该设置为 WriteBack 还是 WriteThrough 的证据。
我想某些子系统可能会比其他子系统更好地处理这个问题，在 SSD 上重新排序排队的 I/O 请求并不重要，因为没有任何寻道时间。
我相信 WriteBack 设置允许控制器在将数据实际写入磁盘之前立即将 I/O 完成消息发送回主机。但在 SSD 上，这种延迟是否显着？
我倾向于直写并放弃备用电池单元，但我很想听听任何关于这方面的子系统 SSD 经验。
【问题讨论】：
标签： caching storage solid-state-drive subsystem
我过去使用 WriteBack 主要有两个原因：
1) 从主机的角度来看，写入速度更快。
2) 重新排序磁盘写入。
更快的写入允许主机写入机箱 RAM，然后继续（当然还有备用电池）。重新排序允许这些写入以不同于从主机接收的顺序发生。当读/写磁头靠近写入位置时，可以随意写入数据。虽然我没有具体阅读过，但我推测，根据编写固件的团队的理解和技能，一些附件在重新排序数据包和延迟写入方面比其他附件更有效。
让我们将 SSD 驱动器与 15k SAS 驱动器进行比较。以 Intel 320 为例，规格显示在读取期间高达 38000 随机 IOPS（写入期间为 14000），而 15k 磁盘可以达到，例如在读取期间 200 随机 IOPS。这将使每个 SSD 驱动器的速度与大约 190 个硬盘驱动器相同。
由于 SSD 不会像旋转磁盘那样通过重新排序写入来提高速度，并且由于 SSD 的高吞吐量，看起来 WriteBack 的用处已基本消除。因此，基于这个逻辑，并且根据我能够找到的研究，我建议将 WriteThrough 用于 SSD SCSI 机箱，同时允许发生读取缓存（有争议）。我还将禁用任何预读缓存方案。预读已经可以移动近 300 MB/秒的东西似乎毫无意义。
在 RAID 机箱中使用 SSD 驱动器时，瓶颈会从磁盘 IOPS 转移到 RAID 机箱链路 (iSCSI/Fibre)，除非您有幸拥有 10GB 的速度。
【讨论】：