[Kevin OBrien]

The Fusion-io ioDrive2 Duo is a full-height, half-length application accelerator that, when paired with SLC NAND, offers 1.2TB of low-latency, high-endurance storage for today's most demanding applications. While branded as a second generation product, the naming is somewhat misleading as Fusion-io has long been a pioneer in the memory-as-storage range with their assorted ioMemory products. That experience shows not just in product development and spec sheet highlights, but all the way through to management as well; Fusion-io boasts the most robust drive management software suite on the market with ioSphere. Still, pretty software and proven drive design are only part of the equation. Enterprises deploy these products with one goal in mind; reduce application response times by attacking storage system latency. The SLC iteration of the ioDrive2 brings laser-focus to this issue, offering read access latency of 47µs and write access latency of 15µs. This compares to read access latency of 68µs in the MLC-based ioDrive2 (they have the same write latency) and while roughly 20µs doesn't sound like much, it can be a virtual eternity for applications that have been tuned for use with flash storage.

Fusion-io ioDrive2 Duo SLC Application Accelerator Review (1.2TB)

[naimc5]

We are currently reviewing a the Duo2 2.4 TB MLC card and I'm seeing a very big drop in the write performance after 12 hours of usage. We are running an indexing application that wrote out 6 TB of data to the fusionIO card in 12 hours After I benchmark using Anvil Storage benchmark and write performance has dropped off by more than 100%.

We are using Windows 2012 server and the fusionIO VLS version 3.2.2 drivers that have native TRIM support. I was not expecting such a big drop in performance given the trip support.

I have not prior experience with Enterprise Flash storage card so I am wondering how you restored the performance to a prior "preconditioning state" ? Would running the Fusion fio-sure-erase do the trick or is it just a matter of leting the device site idle for garbage collection to work and improve write performance.

Naim.

[Kevin OBrien]

Before runs we use the fio-format command which does a secure erase of the drive/controllers specified. I believe fio-sure-erase is a step beyond that that would probably put additional wear on the drive and more towards a security wipe.

[naimc5]

Kevin OBrien, on 16 May 2013 - 04:01 PM, said:

Before runs we use the fio-format command which does a secure erase of the drive/controllers specified. I believe fio-sure-erase is a step beyond that that would probably put additional wear on the drive and more towards a security wipe.

Thank you Kevin, I tried different things yesterday to restore the performance, I started with just re-formating the disk at the NTFS level and issuing a TRIM free space cmd, that improved the performance but not the original values I 1st saw. I then tried the fio-format and that did the job.

I have another question, while our indexing workload is running I'd like to capture a graph similar to the ones you create in your enterprise benchmarks that plot the IOPS over time showing the precondition curve. I was wondering how your captured the data; I guess you generate a steady load using iometer then capture the data using Perfmon recording the Physical Disk:Writes/sec then plotting it out in excel ?.

Naim

[Kevin OBrien]

For those plots we are capturing the output from fio (not anything related to the ioDrive but the fio workload generator) and plotting it.