作為 StorageReview 在測試協議和企業實驗室開發方面持續進步的一部分，我們正在重新審視我們之前審查過的第一代閃存驅動器。 這些對早期 PCIe 閃存設備的重新審查讓我們有機會在推出對第二代 PCIe 存儲卡和應用程序加速器的新審查之前改進和重新校准我們的企業審查流程。 在過去的幾個月裡，我們一直在使用行業領導者提供的第一代和第二代存儲卡進行修訂後的測試方法，因為我們正在研究與企業存儲購買者更相關的測試協議。 在本次評測中，我們再次使用 640GB Fusion ioDrive Duo——這次在 Windows 和 Linux 上使用了更複雜的測試。
作為 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.0 x8
- 操作系統兼容性
- 微軟：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 審查中使用的圖表中。
