Flash Write-Back Caching Limitations

While caching has been around at least as long as the PC itself, the current generation of caching systems that use flash rather than main memory as their cache medium are a different kettle of fish. As the first of these server-side caching products add write-back caching to their bags of tricks, it's important that you, dear reader, understand how write caches really work.

To begin, we have to note that a write cache--regardless of whether it's using NVRAM in an array controller, flash in a hybrid system or flash in a server--can really only accelerate bursts of write traffic. After all, the whole idea of a cache is that it’s a place data can land quickly until it can be written to the backing store.

Just a few years ago, when the write cache on a high-end disk array was just a few gigabytes, cache exhaustion was commonplace. I remember Microsoft's top Exchange guys saying that array or RAID controller caches just didn't matter; a heavy-duty application could run its storage system out of cache in just a few minutes.

Of course, once the write cache is full, any new data has to either be written directly to the backing store, bypassing the cache, or wait for the caching engine to flush some other data to make room. Either way, performance falls back to the speed of the backing store, which is hopefully fast enough so users don’t bring out their torches and pitchforks.

Today, we can easily use a terabyte or more of flash on a single server. Virident (acquired earlier this month by Western Digital subsidiary HGST) this week announced a 4.6-Tbyte half-length, half-height PCIe flash card. These huge caches can accelerate bursts of traffic that last not just minutes but hours. However, it's important to remember that the data eventually has to be written to your backing store.

[Read why Howard Marks doesn't think the limited write endurance of flash-based SSDs is a cause for significant concern in "SSDs And The Write Endurance Bogeyman."]

On some of my pessimistic days, I imagine a team of IT administrators getting a rude surprise a few months after they fire up their latest hybrid storage system. Their applications write just a little more data each day than their SATA disk-based backing store can absorb. During the day, they write 58 Tbytes of new data, and overnight the system flushes 55 Tbytes to the disk.

Everything seems fine until the time comes when there isn't any more free space in the cache. Performance will then drop from the 100,000 IOPS the flash cache was providing to the 1,000 IOPS the RAID-6 SATA backing store can deliver.

The good news is that at least some of the producers of hybrid systems and server side write-back caching software recognize the problem and have built mechanisms into their products that apply back-pressure, delaying each IO just a tiny bit as the cache fills so users will see a more gradual drop in performance.

Users of write-back caching products, regardless of whether they run in a storage system or the server, should watch the amount of data in their cache and act to speed up their backing store if the cache doesn't periodically empty completely. While I can imagine a system that only empties its cache over the weekend working perfectly well, I wouldn’t sleep well at night if my systems didn’t get all their data to the disk within a few hours of when my applications wrote it.

[Get deep insight into how flash-based solid state disks (SSDs) work and how they can be deployed in Howard Marks' session, "SSDs In The Data Center" at Interop New York Sept. 30-Oct. 4.]