Flash is a hot topic with at least a portion of most VARs’ calling bases. In the right implementations, this storage technology can dramatically improve performance of the most important applications customers have. But there are some distinct differences between the design and operation of NAND flash memory devices and those of traditional disk drives. These differences can impact how satisfied customers are with flash devices in what are often their most critical applications.
With flash, writes are made to an entire cell of memory; flash devices can’t overwrite a few hundred bytes like a hard disk drive can. When a flash device is new (referred to as the “fresh out of the box,” or “FOB,” state), this fact is transparent since each new write goes to an already-empty flash cell. But after it’s been filled to capacity, in which case all the cells have been written to once, it’s a different story. This condition (known as “steady state”) requires that before each new write occurs, the controller must erase a cell to make room for it. In this process, called “garbage collection,” the controller copies segments of data that need to be saved and then erases the entire cell.
The result of this process is that steady-state performance is much slower than FOB, although it’s still orders of magnitude better than hard drives. But when two flash devices are being tested, it’s imperative that the steady-state condition be established, since this is where the device will operate for most of its life. Aside from impacting performance, this extra copying process also increases the number of write cycles or “program/erase” (P/E) cycles the device experiences, which impacts endurance.
Originally designed for consumer use in memory sticks and cameras, etc. (by Toshiba, we learned on a briefing call recently), there was no need for flash to be written and rewritten to a large number of times. But when it started being used in the enterprise space, flash endurance became an issue. Enterprise applications, especially the ones that are performance-critical enough to justify the expense of flash storage, generate a lot of read/write activity. Database transaction logs and caching, for example, generate a lot of IOPS, the performance metric most often associated with flash applications.
Flash designers have addressed this problem in a number of ways, but it’s imperative that users (and their VARs) understand how much write traffic they expect to generate on a daily basis. Then they can compare that with a standard endurance metric called “total bytes written” (TBW) to calculate how long that flash device will last in their environment.
Ask your flash vendors about their products’ performance and endurance. See how much they know about these numbers and what they mean and find out if the products you’re selling or looking to sell are going to make your customers happy in the long term. You can also set customers’ expectations around flash as a technology and demonstrate your value as a trusted storage advisor in the process.
We’ll talk more about flash in an upcoming blog. In the meantime, here are some video links on Storage Switzerland about flash performance and endurance.
Follow me on Twitter: EricSSwiss