Fun with Flash Formats

Posted by VIOLIN SYSTEMS on Apr 8, 2015 4:09:47 PM

Like all storage, Flash must be formatted before it’s usable. The format of flash is built around maintaining consistent performance and resiliency. When an all-flash array fills up, it will reuse space to write new data. Erase operations happen in big blocks (megabytes) of space, while writes happen in small chunks (kilobytes). Flash requires you to erase before you can reclaim space to write. The process of reclaiming space by moving existing data to another block is known as garbage collection and when performed as a background activity has no impact on production activity. When it becomes a foreground operation, it significantly reduces production activity.

To keep garbage collection (GC) as a background operation and avoid a negative impact on production activities, most flash vendors use the same trick: overprovisioning (creating a reserve space). The reserve area of flash is beyond the stated capacity of the device and allows for background operations as the GC process converts stale (previously written and now obsolete) pages into free pages available to be written.

For this reason, every flash solution available actually contains more flash memory than it advertises.


In times of heavy write activity the available reserve area begins to decrease. At some point, to avoid a situation where no free pages are available, GC must switch into a mode called foreground garbage collection (also sometimes known as “active garbage collection”) whereby user I/O requests must queue behind system GC I/O requests. This increases latency seen by users – and in high write activity situations it can be dramatic.

There are three major factors which affect the performance of GC. The most obvious is the write workload, since more writes create more demand for available free/reserve space.

A second important factor is the size of the reserve area. Note that Violin Systems is the only flash vendor for which this size is configurable in the field. Most SSDs in particular do not have the ability to configure or even (in most cases) monitor the size and performance of the reserve area.

Finally, the type of flash (SLC, MLC or TLC) has a significant impact on the performance of garbage collection, due to the speed at which write and erase operations take place.

Most SSD-array vendors use SSDs designed for read-intensive environments. Customers cannot change the flash format level in the SSDs. It’s fixed in the SSD by the manufacturer. If you have write-intensive workload you could buy a different vendor’s array for write-intensive workloads with more reserve space.

It also means that you have two vendors, two management consoles, two operating systems, etc… Separate arrays for write or read intensive workloads is not desirable.

With Violin’s Flash Fabric Architecture™, you can have storage pools with different format levels. One Violin array could be formatted at 84% for read-intensive workloads. Another Violin array could be formatted at 65% for write-intensive workloads. These pools are managed from Violin’s Symphony management using a single pane of glass, from a single vendor for simplified management.

Violin gives its customers the ability to match the environment to the workload. You don’t need to struggle with a one-size-fits-all solution. Violin means Business in a Flash.

If you’d like to find out more, including our white paper on Flash Fabric Architecture, go to

Topics: Business Applications, Business