作为 StorageReview 在测试协议和企业实验室开发方面持续进步的一部分，我们正在重新审视我们之前审查过的第一代闪存驱动器。 这些对早期 PCIe 闪存设备的重新审查让我们有机会在推出对第二代 PCIe 存储卡和应用程序加速器的新审查之前改进和重新校准我们的企业审查流程。 在过去的几个月里，我们一直在使用行业领导者提供的第一代和第二代存储卡进行修订后的测试方法，因为我们正在研究与企业存储购买者更相关的测试协议。 在本次评测中，我们再次使用 640GB Fusion ioDrive Duo——这次在 Windows 和 Linux 上使用了更复杂的测试。
由于行业领导者和主要合作伙伴的不断投入，StorageReview 团队评估企业存储的方式不断发展。 这种协作方法使像这样的评论输出更加详细并且与整个行业相关。 与制造商的密切合作使我们能够在持续的基础上将新的测试想法纳入我们的评论中，并涵盖否则可能被忽视的项目。 读者将在下面找到 70 多张图表，这些图表几乎详尽地分析了 ioDrive Duo； 这甚至不包括正在开发的新系列应用程序级基准测试。 虽然这些细节对某些人来说似乎太过分了，但对于需要特定套件来解决存储问题的其他人来说，这些细节至关重要。 为了方便读者，整个评论一如既往地张贴在一个页面中。
在深入探讨 ioDrive 的性能之前，重要的是要强调 Fusion-io 的闪存和典型 SSD 之间的一些主要区别。 SSD 上的闪存（顾名思义，固态硬盘）隐藏在 SATA 或 SAS 接口后面，出于兼容性原因混淆了 NAND。 使用 ioDrive 产品，用户基本上可以访问闪存存储层，它提供比 SSD 低得多的延迟和更好的整体性能。 其原因归结为体系结构以及 ioDrive 与主机系统的接口方式。
企业级 PCIe SSD 通常有多个块设备控制器和一个额外的芯片，用于将多个设备一起 RAID 到一张卡上，而 Fusion-io 则采用不同的方式来实现。 Fusion ioMemory 与 NAND 闪存的接口就像处理器与系统内存的交互一样，这是使用 Fusion-io 的 NAND 控制器 (FPGA) 的组合完成的，它直接通过 PCIe 和 Fusion-io 的驱动程序或安装在闪存上的虚拟存储层软件进行通信主机系统将设备转换为传统的块设备。 通过 Fusion-io 的虚拟存储层或 VSL，该软件模拟块设备以实现兼容性，尽管最近 Fusion-io 发布了一个 SDK，允许 某些应用程序中的本机访问（绕过内核块层）.
IoMemory 也是非传统的，因为它会消耗系统资源来让 VSL 驱动程序发挥作用，利用主机 CPU，同时还会在系统内存中产生占用空间。 根据 Fusion-io 的说法，这种架构更类似于 RAM 的架构，因此得名 ioMemory。 好处包括更快的文件位置查找，即使 ioMemory 占用 CPU，它的使用效率很高，并且实际上通过降低事务延迟来提高性能。 在管理方面，另一个核心架构的好处是，由于 Fusion-io 使用 FPGA 作为 NAND 控制器，它允许非常低级别的软件/固件更新，可以解决错误修复和性能增强。 这与标准 SSD 控制器形成对比，后者只能通过制造新控制器来进行根本性更改。
Fusion-io ioDrive Duo 规格
- 单层电池 (SLC)
- 320GB ioDrive 双核 SLC
- 1.5GB/s 读取带宽 (64kB)
- 1.5GB/s 写入带宽 (64kB)
- 261,000 次读取 IOPS（512 字节）
- 262,000 次写入 IOPS（512 字节）
- 访问延迟 0.026 毫秒（512 字节）
- 640GB ioDrive 双核 SLC
- 1.5GB/s 读取带宽 (64kB)
- 1.5GB/s 写入带宽 (64kB)
- 252,000 次读取 IOPS（512 字节）
- 236,000 次写入 IOPS（512 字节）
- 访问延迟 0.026 毫秒（512 字节）
- 320GB ioDrive 双核 SLC
- 多层单元 (MLC)
- 640GB ioDrive 双核 MLC
- 1.5GB/s 读取带宽 (64kB)
- 1.0GB/s 写入带宽 (64kB)
- 196,000 次读取 IOPS（512 字节）
- 285,000 次写入 IOPS（512 字节）
- 访问延迟 0.029 毫秒（512 字节）
- 1.28TB ioDrive 双核 MLC
- 1.5GB/s 读取带宽 (64kB)
- 1.1GB/s 写入带宽 (64kB)
- 185,000 次读取 IOPS（512 字节）
- 278,000 次写入 IOPS（512 字节）
- 访问延迟 0.03 毫秒（512 字节）
- 640GB ioDrive 双核 MLC
- PCI-Express 2.0x8
- 操作系统兼容性
- 微软：Windows 64 位 Microsoft XP/Vista/Win7/Server 2003/2008/2008 R2
- Linux：RHEL 5/6； SLES 10/11； OEL 5/6； 中央操作系统 5/6； Debian 挤压； 软呢帽 15/16；openSUSE 12； Ubuntu 10/11
- UNIX：Solaris 10 U8/U9/U10 x64； OpenSolaris 2009.06 x64； OSX 10.6/10.7、HP-UX* 11i
- 虚拟机管理程序：VMware ESX 4.0/4.1/ESXi 4.1/5.0、带有 Hyper-V 的 Windows 2008 R2、Hyper-V Server 2008 R2
- 工作温度：0-55C
- 五年保修或使用的最大耐用性
- VSL 版本审核：3.1.1
设计与建造
Fusion ioDrive Duo 是一个全高半长 x8 PCI-Express 卡，有两个单独的 ioDimm 连接到主接口板。 虽然 PCI-Express 卡在机械上是一个 x8 设备，但在 Gen1 平台上它使用 8 通道带宽，而在 PCIe Gen2 系统上它只需要 4 通道。 每张卡代表一个独特的 320GB ioMemory 设备，使用 4 通道的 PCIe 连接。 设计非常紧凑和干净，包括卡背面部分的坚固支撑支架。 这有助于加强卡的强度，使其在恶劣的操作条件下仍能正常工作，并赋予其漂亮的成品外观。
基于 MLC 的 ioDrive Duo 的心脏（或心脏）是两个 ioDimm。 每个相同的 ioDimm 代表一个 ioDrive，具有自己的 Xilinx Virtex-5 FPGA 和 400GB 的 MLC NAND 池。 我们评测的 ioDrive Duo 使用三星 NAND，但 Fusion-io 与制造商无关。 NAND 分为每台设备 25 个双层堆叠 16GB 芯片，其中 320GB 可用于库存格式。 该比率使库存超额配置水平达到 20%，与大多数企业闪存设备大致相当。 Fusion-io 还提供了修改过度配置级别的能力，以允许通过以用户容量换取后台活动来进行定制和提高性能。
从功能的角度来看，ioDrive 都包含指示 LED，显示驱动器从通电到断电的状态。 根据激活的 LED，它将显示卡的以下模式：
- 关闭电源
- 开机（未加载驱动程序，未连接设备）
- 开机（加载驱动程序，未连接设备）
- 主动写入活动
- 主动阅读活动
- 位置信标
对于更传统的方法，ioDrive Duo 还包括一个标准的 HDD 活动 LED 连接器。 此连接允许将计算机机箱的前置 HDD 活动灯连接到 ioDrive Duo。
ioDrive Duo 采用被动冷却方式，包含三个散热器； 专为在强制冷却服务器环境中工作而设计。 这些散热器冷却每个 ioDimm 上的一个 Xilinx Virtex-5 FPGA 以及一个将两个设备与单个 PCIe 插槽连接的 PCIe 开关。 Fusion-io 列出了 300LFM 的推荐气流，环境温度低于 55C。 为防止损坏，ioDrive 设计为在达到 78C 的内部温度并在 85C 时关闭电源时限制性能。 应该注意的是，这些卡不是为工作站环境设计的，因为工作站通常不为库存配置中的 PCIe 附加组件提供冷却支持。 为了应对这些市场， Fusion-io 最近宣布了 ioFX，这基本上是一个具有主动冷却功能的单个 ioDimm。
Fusion “Duo” ioMemory 设备与许多竞争性 PCIe 解决方案之间的另一个区别是，它们需要比 x8 PCIe 2.0 连接通常支持的功率更多的功率才能保持全部性能。 PCIe 2.0 电气规格允许从 x25 连接中提取 8w，在重写条件下，ioDrive Duo 等双 ioDimm 型号可以超过。 虽然它们在不提供额外电源的情况下符合规范，但完整的写入性能将受到限制。 为了解决这个问题，Fusion-io 提供了两种解决方案； 一种是需要外部电源适配器，另一种是允许该卡在支持它的系统中消耗超过 25 瓦的功率。 为了确定哪个选项对安装最有意义，Fusion-io 为大多数第一层服务器提供了服务器配置指南，其中提供了最佳案例设置说明。
为了保护用户数据，Fusion-io 提供了两个关键功能。 首先，Fusion-io 产品包括断电功能，可确保意外断电期间的数据完整性。 对于更罕见的故障，如 NAND 芯片故障，第一代 Fusion-io 设备上的 NAND 架构的一个优势是它们的闪回冗余，允许单个 NAND 故障而无需关闭整个设备。 第二代型号提供自适应闪回，支持多个 NAND 故障。
软件
Fusion-io 在提供广泛的、完善的直观软件产品组合方面处于领先地位，如果存储供应商提供任何软件，很少有存储供应商能够与之匹敌。 Fusion-io 开箱即用，提供实用程序以通过 GUI 和控制台应用程序全面管理所有主要操作系统中的 ioMemory 设备。 管理功能涵盖了方方面面，包括通过交易用户容量轻松管理过度配置以提高性能的方法，监控驱动器统计数据，甚至实时流式传输卡正在做什么的数据。 没有其他 PCIe 存储制造商能够提供这种级别的驱动器管理支持，更不用说这种级别的直观易用性了。
ioSphere Low-Level Format（超量配置进入高性能模式）
ioSphere 软件最有趣的功能之一是能够查看攻击 ioMemory 设备的活动类型。 此信息的范围从带宽和 I/O 活动到当前设备温度、剩余设备寿命，甚至 VSL 驱动程序使用的系统资源。
ioSphere 现场表演流媒体
要查看更多详细信息，还有一个页面提供了当前所选 ioMemory 设备规格的完整打印输出。 这可以是从传输到设备或从设备传输的信息总量到通过 PCIe 总线的当前功耗的任何值。
ioShpere 生命周期使用信息
无论您是喜欢 GUI 还是控制台界面来获取信息或设置 ioDrive Duo，Fusion-io 还提供一整套基于控制台的实用程序来处理从轮询驱动器状态到格式化驱动器的所有事情。 所有这些实用程序都设置为在多个操作系统中工作，因此无论使用哪个平台； 您无需加载备用操作系统即可管理 Fusion-io 产品。
Fusion-io 命令行状态（基本）
测试背景和比较
在测试企业硬件时，环境与用于评估它的测试过程一样重要。 在 StorageReview，我们提供与许多数据中心相同的硬件和基础设施，我们测试的设备最终将用于这些数据中心。 这包括企业服务器以及适当的基础设施设备，如网络、机架空间、电源调节/监控，以及用于正确评估设备性能的同类可比硬件。 我们的评论都不是由我们正在测试的设备的制造商支付或控制的； 我们自行决定从我们实验室的产品中挑选相关的可比产品。
StorageReview 企业测试平台：
联想ThinkServer RD240
- 2 个英特尔至强 X5650（2.66GHz，12MB 缓存）
- Windows Server 2008 Standard Edition R2 SP1 64 位和 CentOS 6.2 64 位
- 英特尔 5500+ ICH10R 芯片组
- 内存 – 8GB (2 x 4GB) 1333Mhz DDR3 Registered RDIMM
640GB Fusion-io ioDrive 双核
- 发布时间：1H2009
- NAND 类型：MLC
- 控制器：2 x 专有
- 设备可见性：JBOD、软件 RAID 取决于操作系统
- 融合 io VSL Windows：3.1.1
- Fusion-io VSL Linux 3.1.1
300GB LSI WarpDrive SLP-300
- 发布时间：1H2010
- NAND 类型：SLC
- 控制器：6 x LSI SandForce SF-1500 通过 LSI SAS2008 PCIe 到 SAS 桥
- 设备可见性：固定硬件 RAID0
- 大规模集成电路视窗：2.10.43.00
- LSI Linus：原生 CentOS 6.2 驱动程序
1.6TB OCZ Z-Drive R4
- 发布时间：2H2011
- NAND 类型：MLC
- 控制器：8 x LSI SandForce SF-2200 通过自定义 OCZ VCA PCIe 转 SAS 桥
- 设备可见性：固定硬件 RAID0
- OCZ Windows 驱动程序：1.3.6.17083
- OCZ Linux 驱动程序：1.0.0.1480
标准综合基准
我们将本次审查的标准合成 IOMeter 测试部分分为两部分。 第一个是我们标准的低队列深度测试，它在每个工人 4 个队列深度下执行（总共 4 个工人分布在两个经理身上）。 初始测试更符合单用户环境，而后半部分更高的队列深度范围更像是卡在 I/O 请求堆积的服务器中看到的情况。
我们的第一个测试着眼于持续突发条件下的直线顺序读写速度。 Fusion-io 在基于 1.5GB MLC 的 ioDrive Duo 上列出了 1.0GB/s 的读取速度和 640GB/s 的写入速度。
我们测量了 1,584MB/s 读取和 1,045MB/s 写入的顺序传输性能。
接下来我们看看大块随机传输，在 IOMeter 中传输 2MB。
在 2MB 随机传输的情况下，ioDrive Duo 保持了 1,589MB/s 的读取速度和 1046MB/s 的写入速度。
我们的下一个测试着眼于低队列深度随机 4K 传输速度，总共有 1 个工作线程，每个工作线程的队列深度为 XNUMX。
在低队列深度下，Fusion ioDrive Duo 提供了最高的性能，读取速度为 189MB/s，写入速度为 366MB/s，或者读取速度为 48,403 IOPS，写入速度为 93,740 IOPS。
在性能和延迟齐头并进的情况下，我们在低队列深度 4K 随机传输测试期间查看了平均延迟和峰值延迟。 Fusion ioDrive Duo 的平均响应时间为 0.0422 毫秒，峰值响应为 2.08 毫秒。
我们综合基准的下半部分是斜坡测试，涵盖从早期队列深度级别到每个工人最多 64 个（有效 QD = 256）或 128 个（有效 QD = 512）的性能。 本节还包括我们的服务器配置文件测试，这些测试从一开始就旨在展示企业产品在要求苛刻的混合服务器负载下的性能。
观察 ioDrive Duo 的随机 4K 读取性能，它在队列深度为 4 和 1 时保持了 LSI WarpDrive 和 OCZ Z-Drive R2 的近两倍速度，领先优势在队列深度为 4 之前下滑被两个竞争模型超越。 在此测试中，队列深度为 140,000 时的读取性能最高为 64 IOPS，但队列深度为 120,000 及以上时，其速度仍保持在 8 IOPS 以上。
切换到斜坡 4K 随机写入测试，ioDrive Duo 显示出类似的性能配置文件，在较低的队列深度上击败了其他竞争模型。 在此测试中，ioDrive Duo 的性能在队列深度为 224,000 时以 4 IOPS 写入速度达到峰值，在队列深度为 201,000 至 210,000 时稳定在 8 至 64 IOPS 之间。
我们的最后一组标准综合基准测试使用我们在 IOMeter 中的服务器配置文件来查看扩展性能。 这些测试测量从低队列深度到每个工作人员最多 128 个（有效 QD=512）的性能。 本节旨在展示企业产品在突发条件下的不同苛刻混合工作负载下的性能表现。 在我们以企业为中心的混合工作负载中，ioDrive Duo 在队列深度为 1 和 2 时处于领先地位（文件服务器测试除外），然后在队列深度最高时落后于其他驱动器。
企业真实世界基准
我们的企业跟踪涵盖 Microsoft Exchange 邮件服务器环境。 我们在几天内捕获了 StorageReview 邮件服务器的活动。 该服务器硬件包括一个运行 Windows Server 2970 R2003 环境的 Dell PowerEdge 2，在 Dell Perc 73/I 集成控制器上以 RAID10 中的三个 5GB 5k SAS 硬盘驱动器运行。 跟踪由许多小的传输请求组成，具有 95% 的强大读取负载和 5% 的写入流量。
由于某些 PCIe 设备需要更高的负载才能达到最佳性能，因此我们同时包含轻型和重型配置文件以进行跟踪播放。 在这种情况下，我们将较弱配置文件中的有效队列深度限制为 8，并在重型配置文件中将其增加到 48。
由于有效队列深度限制为 8，代表较轻的活动条件，ioDrive Duo 在我们的邮件服务器跟踪回放测试中提供了最高的传输速度，平均速度为 969MB/s。 相比之下，在相同条件下，LSI WarpDrive 的平均速度为 508MB/s，OCZ Z-Drive R625 的平均速度为 4MB/s。 将允许的队列深度扩大到 48，Z-Drive R4 以 1,327MB/s 的平均速度位居榜首，ioDrive Duo 以 1,227MB/s 的速度位居第二，而 WarpDrive SLP-300 紧随其后速度为 830MB/s。
增加队列深度以提高传输速率的一种权衡是，随着未完成的 I/O 增加，它会影响响应时间。 轻负载时，ioDrive Duo 保持 969MB/s 的传输速度，响应时间为 0.06ms。 Z-Drive R4 以 1,327MB/s 的传输速度超越它，其响应时间增加了 3.5 倍，达到 0.21ms，而 WarpDrive 的平均响应时间为 0.45ms，传输速率为 830MB/s。
企业综合工作负载分析（库存设置）
我们看待 PCIe 存储解决方案的方式比仅仅关注传统的突发或稳态性能更深入。 查看长时间内的平均性能时，您会忽略设备在整个时间段内的性能背后的细节。 由于闪存性能随时间变化很大，我们新的基准测试过程分析了每个设备整个预处理阶段的总吞吐量、平均延迟、峰值延迟和标准偏差等方面的性能。 对于高端企业产品，延迟通常比吞吐量更重要。 出于这个原因，我们竭尽全力展示我们通过我们的每台设备的全部性能特征 企业测试实验室.
我们还添加了性能比较，以显示每个设备在 Windows 和 Linux 操作系统的不同驱动程序集下的性能。 对于 Windows，我们在最初审查时使用最新的驱动程序，然后在 64 位 Windows Server 2008 R2 环境下对每台设备进行测试。 对于 Linux，我们使用 64 位 CentOS 6.2 环境，每个 Enterprise PCIe Application Accelerator 都支持该环境。 我们进行此测试的主要目标是展示操作系统性能的差异，因为在产品表上将操作系统列为兼容并不总是意味着它们之间的性能相同。
所有经过测试的设备从头到尾都遵循相同的测试策略。 目前，对于每个单独的工作负载，设备都使用供应商提供的工具进行安全擦除，以相同的工作负载预处理到稳定状态，设备将在 16 个线程的重负载下进行测试，每个线程有 16 个未完成队列，并且然后在多个线程/队列深度配置文件中以设定的时间间隔进行测试，以显示轻度和重度使用情况下的性能。 对于具有 100% 读取活动的测试，预处理使用相同的工作负载，但翻转为 100% 写入。
预处理和初级稳态测试：
- 吞吐量（读+写 IOPS 聚合）
- 平均延迟（读+写延迟一起平均）
- 最大延迟（峰值读取或写入延迟）
- 延迟标准偏差（读+写标准偏差一起平均）
目前，Enterprise Synthetic Workload Analysis 包括四个通用配置文件，它们可以尝试反映真实世界的活动。 选择这些与我们过去的基准有一些相似之处，以及与广泛发布的值（例如最大 4K 读写速度）以及企业驱动器常用的 8K 70/30 进行比较的共同点。 我们还包括两个遗留的混合工作负载，包括传统的文件服务器和 Web 服务器，提供各种传输大小。 最后两个将随着我们网站上介绍的那些类别的应用程序基准逐步淘汰，并替换为新的合成工作负载。
- 4K
- 100% 读取或 100% 写入
- 100% 4K
- 8K 70/30
- 70% 读取，30% 写入
- 100% 8K
- 文件服务器
- 80% 读取，20% 写入
- 10% 512b、5% 1k、5% 2k、60% 4k、2% 8k、4% 16k、4% 32k、10% 64k
- 支持网络端
- 100% 阅读
- 22% 512b、15% 1k、8% 2k、23% 4k、15% 8k、2% 16k、6% 32k、7% 64k、1% 128k、1% 512k
查看在 100 小时内 4 个线程和 16 个队列的重负载下的 16% 6K 写入活动，我们发现 Fusion ioDrive Duo 在我们的 Lenovo ThinkServer RD240 中提供了最高的峰值传输速度。 这适用于 Windows Server 2008 R2 64 位和 CentOS 6.2，后者在 Windows 性能上略有领先。 接下来是 1.6TB 的 OCZ Z-Drive R4，尽管仅在 Windows 中。 CentOS 6.2 [1.0.0.1480] 的 OCZ 驱动程序无法正确响应更高的队列深度请求，无论线程数量如何，并且在整个测试阶段保持大约 7,600 IOPS 的速度。 接下来是 LSI WarpDrive SLP-300，它在 Windows 和 Linux 中提供了非常相似的吞吐量。
查看我们 4K 100% 写入预处理测试期间的平均延迟，最快和最慢的驱动器是 OCZ Z-Drive R4。 在 Windows 环境中，驱动程序完全正常工作，平均延迟比 Fusion ioDrive Duo 或 LSI WarpDrive 快得多。 在性能相当低迷的 Linux 环境中，它比该类别中的其他设备呈指数级增长。
深入研究 4K 100% 写入预处理测试期间每个间隔的最大延迟输出，您可以开始了解影响控制器和 NAND 在重写入环境中发挥的作用有多大。 就峰值延迟峰值而言，采用 MLC NAND 的 Fusion ioDrive Duo 介于基于 SLC 的 LSI WarpDrive 和基于 MLC 的 OCZ Z-Drive R4 之间。 比较 Windows 和 Linux 中的性能，我们发现 Windows 环境中的输出比 Linux 更一致，尖峰更少，但不是更小。 Windows 中基于 MLC 的 Z-Drive R4 有很大的峰值，远高于我们的图表规模，Linux 性能相当稳定，尽管在低 IOPS 性能下远未完成繁重的任务。 LSI WarpDrive 在 Windows 中提供了其最佳性能，具有更平坦的延迟曲线，尽管它仍然看到一个超过 1,000 毫秒的尖峰。
在考虑特定存储产品的最大延迟性能时，经常被忽略的区域是数千或数百万个 I/O 中有多少具有高响应值。 这就是为什么不仅要监控峰值延迟以查看最高峰，还要查看标准偏差（显示延迟的变化）的重要性。 即使驱动器具有相当低的平均延迟且所有值均已平均，它仍可能具有相当大量的 I/O，根据您使用的应用程序，这些 I/O 可能被认为是不可接受的。
使用 SLC NAND 配置，LSI WarpDrive 保持了非常好的延迟标准偏差，其优势主要体现在 Windows 环境中。 Fusion ioDrive Duo 接近标准偏差的上限，尽管它相当一致，就像在 WarpDrive 中发现的模式一样。 比较其驱动程序性能，在此特定测试中，它在 Linux 中始终更快。 在我们的测试期间，OCZ Z-Drive R4 的延迟输出范围很广，尽管它在达到稳定状态后有时会开始趋于平衡，但仍然有一段时间再次出现高延迟。
预处理测试完成后，我们立即开始进行初步测试抽样。 在稳定状态下，该组中吞吐量最高的 PCIe 存储设备是 Windows 中的 OCZ Z-Drive R4。 它测得的读取峰值为 229,811 IOPS，写入速度为 56,978 IOPS。 接下来是 Fusion ioDrive Duo，读取 140,230 IOPS，写入 42,644 IOPS。 ioDrive Duo 的 Windows 性能略低于此，写入性能略有下降。 LSI WarpDrive SLP-300 在 Windows 中提供了最强的 4K 写入速度，测量为 120,502 IOPS 读取和 35,015 IOPS 写入。
在高负载 4K 读取和 4K 写入的稳态测量中，OCZ Z-Drive R4 凭借其在 Windows 中同类领先的吞吐速度名列前茅，平均读取延迟为 4.49 毫秒，写入延迟为 1.11 毫秒。 Fusion ioDrive Duo 紧随其后，其读取速度在 Linux 中为 6.00 毫秒，在 Windows 中为 6.25 毫秒，在两个操作系统中的写入速度均为 1.82 毫秒。 接下来是 WarpDrive，在 Windows 中的读取速度为 7.31 毫秒，在 Linux 中的读取速度为 7.32 毫秒，在 Windows 中的写入速度为 2.12 毫秒，在 Linux 中为 2.71 毫秒。
查看稳态测试采样时间的峰值延迟，基于 SLC 的 LSI WarpDrive 在 Windows 和 Linux 中均处于最低或最佳状态，其次是 Windows 中的 Fusion ioDrive Duo，峰值读取时间为 426.15 毫秒和 170.09 毫秒峰值写入，然后在 Linux 中读取峰值为 1,208 毫秒，写入峰值为 156.91 毫秒。 在 Windows 中，OCZ Z-Drive R4 的峰值最高，在 Windows 中读取时间为 1,889 毫秒，写入时间为 5,299 毫秒。
查看我们稳态 4K 读写测试期间的标准偏差，在我们的 4K 读写活动测试中最一致的 PCIe 应用程序加速器是 Windows 中的 LSI WarpDrive。 按照一致的 4K 写入性能排名，Windows 中的 OCZ Z-Drive R4 紧随其后，其次是 Linux 中的 WarpDrive，其次是 Linux 中的 ioDrive Duo，然后是 Windows 中的 ioDrive Duo。 以始终如一的快速读取速度排名，ioDrive Duo 的 Windows 和 Linux 性能排在基于 SLC 的 WarpDrive 之后，然后是 Linux 中的 WarpDrive，然后是 Windows 中的 Z-Drive R4。
与我们的 100K 测试中的 4% 写入活动相比，下一个预处理测试使用更真实的读/写工作负载分布。 在这里，我们有 70% 的读取和 30% 的写入混合 8K 传输。 在 8 小时的 70 个线程和 30 个队列的重负载下，查看我们的 16K 16/6 混合工作负载，我们发现 Fusion ioDrive Duo 仍然提供我们 Lenovo ThinkServer 中最高的峰值传输速度。 这适用于 Windows Server 2008 R2 64 位和 CentOS 6.2 环境，恰好在 Windows 性能上略有领先。 接下来是 1.6TB 的 OCZ Z-Drive R4，尽管仅在 Windows 中。 接下来是 LSI WarpDrive SLP-300，它在 Windows 环境中提供了更高的性能。
转而查看我们 8K 70/30 测试中的平均延迟，驱动程序集之间的差异变得更加明显。 Fusion ioDrive Duo 在 Linux 和 Windows 之间具有最相似的性能，尽管随着驱动器达到稳定状态，Linux 驱动程序集的优势变得更加明显。 LSI WarpDrive 显示驱动程序集之间的平均延迟存在显着差异，其中 Windows 驱动程序提供最高性能。 Windows 中的 OCZ Z-Drive R4 在该组中具有最低的平均延迟，同时具有最快的吞吐量。 Linux 性能虽然再次超出图表，但在 Linux 中平均约为 46 毫秒，而在 Windows 中约为 6 毫秒。
查看 ioDrive Duo、WarpDrive 和 Z-Drive R4 的峰值响应时间，我们在 4K 测试中看到的许多相同特征在我们的 8K 70/30 工作负载中发挥作用，包括读取活动。 在此测试中，Fusion-io ioDrive Duo 以最低的峰值延迟曲线开始，然后在两个小时后随着驱动器开始过渡到稳定状态而开始回升。 当时，它排在 Windows 中的 WarpDrive 之上，这是该组驱动器中曲线最低的。 查看 Windows 和 Linux 中 ioDrive Duo 之间的驱动程序差异，Linux 驱动程序具有更高的峰值，尽管在测试的后半部分它保持较低（更快）的曲线。 另一方面，Windows 中的 Z-Drive R4 具有更高的峰值，尽管与其在 100% 写入工作负载中的行为相比，整体上平静下来。
我们在 8K 70/30 工作负载的预处理阶段的标准偏差配置文件显示了卡之间在测试期间的表现方面的有趣差异。 虽然 WarpDrive 在 Windows 中始终具有最快的响应时间，但其在 Linux 中的延迟性能仍有一些不足之处。 ioDrive Duo 在 Linux 中表现最好，而 OCZ Z-Drive R4 在此测试中与 100% 写入 4K 测试相比产生了大大改善的延迟标准偏差配置文件。
与我们在 16% 16K 写入测试中执行的固定 100 线程、4 队列最大工作负载相比，我们的混合工作负载配置文件可在各种线程/队列组合中扩展性能。 在这些测试中，我们将工作负载强度从 2 个线程和 2 个队列扩展到 16 个线程和 16 个队列。 最奇怪的配置文件是 OCZ Z-Drive R4，将其 Windows 性能与 Linux 性能进行了比较。 在 Windows 中它最快的时候它在 Linux 中最慢，我们测试的驱动程序中存在队列深度缩放问题。 在线程和队列深度较低的情况下，ioDrive Duo 在性能方面远远领先于 LSI SandForce 驱动的 WarpDrive 和 Z-Drive R4。 但是，随着队列深度的增加，其他卡的性能能够达到或超过它。 比较 Windows 和 Linux 驱动程序环境，ioDrive Duo 在整个工作负载中的性能几乎持平。
比较不同级别线程和队列活动的平均完成延迟，WarpDrive 在大多数情况下保持最短的响应时间，直到 Windows 中的 Z-Drive R4 在更高的队列深度负载下超过它。 ioDrive Duo 在 Windows 和 Linux 中提供了几乎相同的性能，在其最高输出水平上只有很小的差距，领先于 Linux 驱动程序集。
查看我们 8K 70/30 工作负载的最大延迟很有趣，因为它表明即使线程和队列数量较少，驱动器仍然会出现高峰值响应时间。 Linux 中的 ioDrive Duo 在大多数工作负载中均出现 1,000 毫秒的峰值，而 Windows 驱动程序则要平静得多。 在此特定测试中，Windows 中的 ioDrive Duo 在 16T/16Q 负载之前的峰值响应时间最低，WarpDrive 紧随其后。
虽然偶尔出现的高峰值可能看起来令人沮丧，但查看标准偏差延迟图，我们发现除 Linux 中的 Z-Drive R4 外，所有设备的延迟配置文件都要温和得多。 在最高负载之前，Windows 中的 ioDrive Duo 保持最低标准偏差，Linux 驱动程序略微落后，其次是 WarpDrive，然后是 Windows 中的 Z-Drive R4。
文件服务器工作负载代表了每个特定设备的更大传输大小频谱，因此驱动器必须处理从 4b 到 8K 的请求，而不是适应静态 512k 或 64k 工作负载。 在本节中，Windows 中的 Z-Drive R4 以最高的突发和稳态性能脱颖而出，其次是 ioDrive Duo。 在突发模式下，Windows 中的 ioDrive Duo 提供更高的速度，然后在驱动器进入稳定状态时与 Linux 性能翻转。 WarpDrive 紧随其后，其 Windows 性能在突发模式和稳态模式下都更高。
查看文件服务器预处理测试的平均延迟，Z-Drive R4 在 Windows 中领先于 ioDrive Duo 和 WarpDrive。 ioDrive 在 Linux 和 Windows 性能之间的差异很小，而 WarpDrive 在操作系统之间的差异更大。
查看每个驱动器预处理阶段的最大延迟，LSI WarpDrive 显示出一些弱点，其 Linux 最大响应时间比其 Windows 时间快了近 400 毫秒。 Linux 中的 ioDrive Duo 响应峰值高于 Windows，尽管在测试期间大多数响应峰值在测试中最低，而 Windows 端几乎没有高延迟峰值，尽管平均浮动较高。 基于 MLC 的 OCZ Z-Drive R4 在文件服务器预处理过程的大部分时间里都出现抖动，在测试的第一个小时内出现了超过 10,000-40,000 毫秒的峰值。
检查通过我们的文件服务器预处理测试运行的设备的标准偏差，最令人惊讶的差异实际上是在 LSI WarpDrive 上发现的，与 Windows 性能相比，其 Linux I/O 响应时间在测试期间显着增加。 当驱动器达到稳定状态时，ioDrive Duo 出现了类似的变化，此时两条路径都发生了分歧，Windows 的响应能力变得不那么集中了。 总的来说，这部分表现最好的驱动器是Windows下的LSI WarpDrive，它在整个测试过程中保持了最平坦的标准偏差曲线。
一旦我们的预处理过程在 16T/16Q 高负载下完成，我们就会查看文件服务器在各种活动级别的性能。 Fusion-io ioDrive Duo 在低线程数和队列数下保持最高性能，仅在更高的出色 I/O 水平下被 OCZ Z-Drive R4 吞吐量超越。
通过分析我们不同负载测试的平均延迟，Z-Drive R4 在我们的测试中以最快的平均响应时间名列前茅。 随着每个线程数的未完成队列级别增加，ioDrive Duo 的延迟在其 Linux 端出现，尽管 Windows 驱动程序的吞吐量略低。
查看我们主要文件服务器测试期间的最大延迟，Linux 中的 ioDrive 在低线程/队列计数级别和高线程/队列计数级别仍显示出 1,000 毫秒的更高峰值。 它的 Windows 对应物虽然提供了最低的一致最大响应时间，直到 16T/16Q 工作负载。
ioDrive Duo 和 WarpDrive 的文件服务器标准偏差配置文件在 Windows 和 Linux 中保持相当紧密，直到更高的有效队列深度。 在 ioDrive Duo 的情况下，Linux 驱动程序在 16T/16Q 级别保持更好的镇定，Windows 性能分散。
我们最后的工作负载在分析测试版本主要输出的预处理阶段的方式上相当独特。 作为以 100% 读取活动设计的工作负载，如果没有适当的预处理步骤，很难显示每个设备的真实读取性能。 为了保持调节工作负载与测试工作负载相同，我们将模式反转为 100% 写入。 出于这个原因，预处理图表比最终的工作负载数字要生动得多。 在这些恶劣条件下，OCZ Z-Drive R4 从突发状态到稳定状态保持了最高吞吐量，ioDrive Duo 紧随其后，WarpDrive 紧随其后。
100% 写入 Web 服务器预处理过程的平均延迟显示 Linux 中的 ioDrive Duo 具有响应时间略低于 Windows 驱动程序集的优势。 LSI WarpDrive 显示出几乎相同的平均响应时间，而 Z-Drive R4 在 Windows 和 Linux 性能之间存在巨大差异。
查看 Web 服务器预调节曲线中的最大延迟，Z-Drive R4 的峰值最高，但一旦趋于平稳，其高延迟尖峰的数量就会减少。 看看 ioDrive Duo，虽然它的 Linux 性能在吞吐量和平均响应时间方面具有优势，但它在本次测试中有一些最高的峰值，超过 1,200 毫秒，而 Windows 驱动程序则要平静得多，其峰值通常在300-400 毫秒范围（除了超过 1,600 毫秒的一个大尖峰）。
基于 SLC 的 LSI WarpDrive 在 Windows 中的 Web 服务器预处理过程中保持最低标准偏差配置文件，一旦平静下来，Z-Drive R4 紧随其后，其次是带有 Linux 驱动程序的 WarpDrive，然后是Linux 中的 ioDrive Duo，然后是 Windows。
在预处理过程后切换回 100% 读取 Web 服务器工作负载，OCZ Z-Drive R4 无疑提供了 Windows 性能中的最高性能，最高吞吐速度超过两倍。 同时，它与它的 Linux 性能形成对比，它在 Windows 中提供最高性能的同时也是最慢的。 ioDrive Duo 以最小的工作负载再次以最快的速度名列前茅，但一旦有效队列深度增加，它很快就会被 Z-Drive R4 超越。
ioDrive Duo 和 WarpDrive 在 Web 服务器平均延迟测试中保持接近，尽管它们在 Windows 中被 R4 轻松击败。
在读取密集型 Web 服务器测试中看到 1,000 毫秒范围内的一些较高延迟峰值仍然存在，这有点令人惊讶，尽管这种行为在 Linux 中的 ioDrive Duo 上最为常见，但在所有三台设备上都注意到了这一点测试中的不同点。
Web 服务器活动的标准偏差图显示 ioDrive Duo 在队列深度速率较高时始终具有较长的响应时间，峰值为 16T/16Q。 这是 Windows 性能在最高工作负载之前一直很紧张的时候。 LSI WarpDrive 保持相当平坦的配置文件，直到 Linux 端的延迟开始出现波动为止。
企业综合工作负载分析（高性能模式）
在本次评测的三个 PCIe 应用程序加速器中，只有 Fusion-io ioDrive Duo 提供了一种方法来更改扇区大小或用户可见的格式化空间以提高性能。 虽然可以将驱动器的一部分分区而不与其他产品一起使用，但该过程并不那么直观。 有些人甚至没有意识到以容量换取性能增益的含义。
虽然这篇评论的大部分内容都集中在 ioDrive Duo 的库存功能上，但剩下的部分将重新审视我们新的综合工作负载分析，以了解高性能模式和库存配置之间的性能差异。 在每台设备 320GB 的库存大小下，ioDrive Duo 在 RAW NAND 和用户可见之间有 20% 的超额配置。 将 ioDrive Duo 格式化为高性能模式会将容量降至 256GB，或 36% 的超额配置，从而使总容量从 640GB 降至 512GB。 当您交易大量可用容量时，我们对它对稳态性能的影响程度感到惊讶。 在某些情况下，我们看到性能翻了一番以上。
将 ioDrive Duo 置于高性能模式后，4K 100% 写入突发速度大致保持不变，约为 257k IOPS，但稳态性能差异显着。 虽然库存配置的 ioDrive Duo 在预处理阶段结束时保持 41-42k IOPS 的吞吐速度，但高性能模式将水平提高到约 90,000 IOPS。 通过牺牲一些用户容量，这不仅仅是 2 倍的跳跃。
与更快的吞吐量携手并进，4K 写入预处理阶段的延迟也减少了一半。
在查看 4K 写入预处理测试的最大延迟配置文件时，许多相同的特征仍然存在，尽管这次要低得多。 Windows 4K 延迟最初略高，但在 Linux 环境中出现的高延迟峰值较少。 当驱动器格式化为高性能模式时，Windows 配置文件仍然有更多的抖动，但 Linux 配置文件有更好的镇静并且没有以前看到的高延迟尖峰。
显示 ioDrive Duo 在高性能模式下显着改进的最有说服力的图表是延迟标准偏差配置文件。 随着后台 GC 活动空间的增加，在全 4K 100% 写入负载下，标准偏差从之前的 25-30ms 减少到 2-5ms。
比较我们在标准模式和高性能模式之间的稳态 4K 100% 读写分数，我们发现读取性能没有提高。 这并不少见，因为过度配置通常只会提高稳态写入速度，而不会影响读取或写入突发速度。 在这种情况下，100% 4K 读取性能保持在略高于 140,000 IOPS，稳态写入性能从 40.9-42.6K 跃升至 90.4-91K IOPS。
我们最初在预处理阶段观察到的 4K 写入延迟的改善在高性能模式 ioDrive Duo 上平均为 2.80-2.82 毫秒，而在标准模式下为 6-6.25 毫秒。
尽管我们没有测量到 4K 读取平均响应时间明显减少或吞吐量增加，但高性能配置的 ioDrive Duo 提供了低得多的峰值读取响应。 峰值 4K 写入响应时间也大幅减少。
两种超额配置模式之间的标准偏差差别很大，高性能 ioDrive Duo 测量为 1.70-1.76 毫秒，而之前为 25.6-31.6 毫秒。
虽然随机 4K 写入性能的性能提升令人印象深刻，但我们更感兴趣的是看到 ioDrive Duo 在混合工作负载中如何变化，其中包含读取活动。 在我们的 8K 70/30 预处理测试中，吞吐量从 51-53k IOPS 范围显着增加到高性能模式下的大约 76K IOPS。 格式化配置之间的突发速度非常相似，尽管过度配置的 ioDrive Duo 开始更快地进入稳定状态。
查看我们 8K 70/30 工作负载的延迟，在高性能模式下，ioDrive Duo 上的 Linux 和 Windows 驱动程序之间的适度差异消失了。 平均延迟显着下降，并且在预处理过程中保持非常一致。
虽然吞吐量和平均延迟改进很重要，但峰值延迟是更改 ioDrive Duo 配置时需要注意的另一个因素。 在这种情况下，额外的超额配置空间为驱动器提供了足够的后台空间，抑制了我们在尖峰配置中看到的大部分最大延迟跳跃。 话虽如此，它们并没有完全消失，但大部分活动都下降到了更低的水平。
查看延迟标准偏差，您可以全面了解为 ioDrive Duo 提供一些额外的过度配置空间会产生多大的影响。 标准偏差下降了 5 倍，在整个预处理过程中保持在 2 毫秒左右，而之前为 8-12 毫秒。
在我们的主要吞吐量测试中，ioDrive Duo 继续全面展示性能优势，我们在 2T/2Q 和 16T/16Q 之间改变负载。
查看我们的 8K 70/30 工作负载的平均延迟差异，将 ioDrive Duo 库存与高性能模式进行比较，差异在每个线程数的较高队列深度处最为显着。
正如我们在 8K 70/30 预处理测试的最大延迟阶段所看到的那样，在测试期间，许多相同的峰值仍然存在，尽管它们的数量较少。
全面比较延迟标准偏差，过度配置对一些增加的队列深度负载产生了最大的影响，而 8T/16Q 等区域根本没有看到任何变化。
Fusion ioDrive Duo 并没有看到通过增加预留空间量来提高总吞吐量。 与在 100% 4K 写入或 8K 70/30% 工作负载中发现的戏剧性跳跃相比，性能仍然有所提高，尽管增加幅度不大。
随着 ioDrive Duo 接近稳态性能，文件服务器预处理测试期间的平均延迟从大约 7-7.5 毫秒改善到略高于 6 毫秒。
尽管 Fusion ioDrive Duo 在吞吐量或平均延迟方面没有显着改善，但它能够抑制在库存过度配置配置中发现的许多高延迟峰值。 最大的改进发生在 Windows 驱动程序上，它在稳定状态下的峰值延迟上限保持在 50-75 毫秒左右，而之前的范围为 225-250 毫秒。
分析文件服务器预处理测试中的延迟标准偏差，一旦驱动器接近稳态，增加的过度配置将抖动保持在最低水平。 Linux 延迟标准偏差并没有太大改善，但 Windows 标准偏差从 12-14 毫秒下降到略低于 3 毫秒。
增加 Fusion ioDrive Duo 的超额配置允许该卡在大多数线程和队列深度组合上提高大约 5,000 IOPS 的性能，在更高的队列深度负载下提高最大。
延迟在这两个方面都得到了改善，Windows 中的 Fusin ioDrive Duo 在 16T/16Q 负载下获得了最大的改善，从最慢到最快。
比较文件服务器工作负载中的峰值延迟，ioDrive Duo 在 Linux 中大大平静下来，失去了许多之前的 1,000 毫秒峰值。 这一次它在 Windows 测试中只有一个 1,000 毫秒的峰值。
全面的标准偏差下降了很多，表明 ioDrive Duo 随着过度配置量的增加而平静下来。
虽然我们的 Web 服务器预调节曲线不是 Web 服务器活动的最佳表示，实际上它在 100% 写入时恰恰相反，但它仍然显示增加的过度配置可能产生的影响有多大。 总吞吐量增加了很多，甚至超过了 OCZ Z-Drive R4。
在我们的 Web 服务器预处理测试期间，平均延迟减少了一半，从之前的 20 多毫秒减少到高性能模式下的略多于 10 毫秒。
几乎所有的高延迟峰值都被增加的过度配置所抑制，其中 Linux 性能提高最多。
在 Web 服务器预处理部分的持续时间内，延迟标准偏差显着改善，Linux 方面的变化最大，与股票表现相比，曲线几乎是平坦的。
将 Web 服务器配置文件切换回 100% 读取，我们发现库存之间的吞吐速度几乎没有或没有提高，并且在这个特定的工作负载中增加了过度配置。 但这并不奇怪，因为过度配置实际上只会有利于与写入相关的性能。
平均延迟几乎完全相同，几乎没有显示出随着额外的过度配置而改善的迹象。
虽然吞吐量和平均延迟没有改善，但当过度配置级别增加时，高延迟响应时间在这个 100% 读取的 Web 服务器配置文件中完全消失了。
与我们在高性能模式下使用 ioDrive Duo 的 Web 服务器配置文件中峰值延迟的降低类似，在我们的 Linux 测试中，延迟标准差也大幅下降，而 Windows 测试的改进微乎其微。
结语
当重新审视 ioDrive Duo 时，有几件事很突出。 鉴于 Fusion-io 是这种特定存储技术迭代的早期先驱，并且他们拥有多项存储方面的关键知识产权，因此整体封装如此紧凑也就不足为奇了，但精度水平值得信用。 这不仅仅是性能方面的精确性，即使作为上一代技术，它也表现出色。 但是，从包装到软件界面，再到在许多受支持的平台（包括我们测试的 Windows 和 Linux 版本）上的一致性能，处处都体现出精致的感觉。 虽然当前的 ioDrive Duo 自首次发布以来已经进行了多次软件更新，但考虑到该驱动器于 2009 年初问世，它的年龄很小。
对于基于 MLC 的驱动器，ioDrive Duo 与基于 SLC 的 LSI WarpDrive 相比，可以认为是其最接近的竞争对手。 作为专为企业应用程序加速细分市场设计的产品，这两种型号都擅长跨多个操作系统平台处理繁重的工作负载。 在几乎所有测试中，ioDrive Duo 都提供了一致的性能，尽管在最大延迟方面，配备 SLC-NAND 的 WarpDrive 比我们配备 MLC 的 640GB ioDrive Duo 表现更好。 将其与基于 MLC 的 OCZ Z-Drive R4 进行比较时，很容易看出这两种产品是如何为截然不同的市场设计的。 由于成本较低的消费级 NAND 和新一代控制器，Z-Drive 提供了高速和大容量，但其峰值延迟和标准偏差比 ioDrive Duo 或 WarpDrive 更不一致。 Z-Drives 的优势更多地体现在重读方面，而 ioDrive Duo 和 WarpDrive 在重写环境中找到了自己的位置。 对于 Windows 之外的部署，ioDrive Duo 和 WarpDrive 在 Linux 中都提供了相似的性能，Z-Drive R4 的性能与其 Windows 分数形成鲜明对比，整体性能呈指数级下降。
当然，库存容量的 ioDrive Duo 并非没有缺点，正如其在稳定状态下在低和高队列深度测试中频繁出现 1,000 毫秒的光点所看到的那样。 但是，考虑到一致的标准偏差，其中许多光点都是少数时间事件，而不是始终如一地达到更高的响应率。 根据平台的不同，可能会发现另一个次要问题，因为 Linux 往往是该产品的强项，即使它仅略微优于 Windows 性能。 不过归根结底，这些延迟问题可能不会出现在基于 SLC 的 ioDrive Duo 中，它可以被视为 LSI WarpDrive 更接近的竞争对手，后者仅在 300GB SLC 配置中可用。
当我们在高性能模式下测试 ioDrive Duo 时，格式化后的容量从每个 ioDimm 的 256GB 降至 320GB，在某些情况下性能翻了一番以上。 4K 随机写入性能从 40,000 IOPS 飙升至 90,000 IOPS，同时峰值延迟急剧下降。 对于愿意以速度和低延迟的名义交换容量的企业用户，Fusion-io 为最终用户提供了一种简单的方法来进行这些更改。 没有竞争的 PCIe 解决方案提供这种类型的性能配置，除非您愿意手动分区用户空间并留下未使用的部分，这在所有应用程序中可能不可行。
优点
- 来自任何 PCIe 应用加速器供应商的软件和硬件的最紧密集成
- Windows 和 Linux 驱动程序之间最接近的性能对等
- 库存模式下的吞吐量和延迟在高性能模式下变得更好
- 强大的低队列/低线程数性能
缺点
- 安装和初始设置可能比其他解决方案更困难（需要外部电源，不支持内置操作系统驱动程序）
- 需要更多系统资源和 VSL 占用空间，用于将 ioDrive 呈现为内存层
底线
从易用性的角度来看，ioDrive Duo 为如何向最终用户展示 PCIe 应用程序加速器设定了标准。 无论使用何种操作系统，体验几乎相同，直至提供的 GUI 和控制台管理工具。 从第一天起，无论操作系统如何，用户都可以坐下来获取 ioDrive Duo 的硬件状态，根据自己的喜好格式化或过度配置，然后投入生产。 ioDrive Duo 是一个完整的产品，比企业存储市场上的任何其他产品都更加精致。
更新 8/17/12 - 我们的 LSI Nytro WarpDrive 评论 已发布并附加到本次 Fusion-io 审查中使用的图表中。
Amazon