The concept of putting a cache in front of storage to improve performance is back again. The last time I remember this happening was in the early 2000s, and it failed miserably. Yes it did work for some application areas, but for the most part, the concepts did not work very well for general purpose storage.
This time the idea is back with a few twists. First, the disk drive vendors have gotten into the mix by planning to put flash right on the drive. And the appliance vendors are in the mix with larger flash caches because the cost of NAND flash is much lower than the cost of DRAM, which was used previously.
If you have read my column in the past, you know I have a saying that there are no new engineering problems, just new engineers solving old problems. This is the case for caches, whether they are flash- or DDR-based.
So what are the issues today with the new designs? What is different than it was before? What are the application issues and what is going to work better this time—disk drives or flash appliances?
With these questions, there is one big consideration. File systems allocate space based on a number of factors, such as the volume manager, number of threads for allocation etc. File systems allocations are not necessarily sequential even for a single file, as allocation is often FIFO (first in first out), and with multiple threads writing to different files, the files will likely be interspersed with most file systems. Also, consider that there might be mismatches between allocations, sizes, volume manager stripe sizes, RAID stripes sizes and/or cache stripe sizes depending on the system. So even if you think a file can be cached because the file fits in the cache, it really depends on how everything is allocated in the whole path it might not be correct.
As always I look at the requirements and technology second. A close friend of mine used to say cache for storage is for hiding latency or to allow the system to consolidate requests to allow bigger requests for storage. If you cannot meet one or both of these criteria, cache will not work. My friend said this in the 1980s about using SSD cache on the Cray YMP, and the statement still holds true today.
The first questions I always ask people when talking about caching systems include the following:
- Are you reading, writing, both and/or write and then read?
- How big is/are the file(s)?
- How are you accessing the file(s)?
- How many people are working in the file system?
One of the key things to remember is storage is about block and block reuse. Disk drives, cache and the like only know about SCSI commands for blocks of data. They do not know about files at the device layer. Of course, at upper layers there is some knowledge, but once you are at the device layer, it is about blocks and not about files or objects.
Are you reading, writing, both and/or write and then read?
How is the data being accessed? Cache is designed to work well if you are reusing data. If you are not reusing data and there are write streams, it is very difficult for a caching system to know that the write stream is not going to be read. It is even harder if it is read some times and not others. It is easy to read ahead data if it is going to be used, but unless the data is read again, then this does not provide much value over the standard caching using the DDR and or NAND flash included in a common storage controller or RAID card.
How big is/are the file(s)?
If your files are bigger than the cache, there is a good chance that cache is not going to help much. File size is an important consideration when using caches.
How are you accessing the file(s)?
Is data being reused? Understanding the access patterns of the data is critical. If you have 1 TB of cache and 50 TB of files but only use 800 GB of the file data, clearly that will fit in cache. But if the working set is 5 TB, that is not going to work very well.
How many people are working?
I have seen many places where cache works some of the time and does not work others based on the number of users. This should not be a surprise.