IBM Zurich wants to spice up your life with SALSA translation layer
Storage boffins get flash and disk dancing together
Research gnomes at IBM Zurich say we should take translation layers off storage devices and run many at the same time on a server to get faster IO.
They have published a research paper discussing this. An SSD has a Flash Translation Layer (FTL), which interfaces between the database and file system concepts on the host system and physical pages and blocks used on the SSD. For example, when writing the SSD has to erase data in a block of pages before writing the fresh data. Upper layer database and file system software in a server knows nothing about this.
The SSD's FTL is constrained by the processing and memory available on the SSD and is only aware of its own local flash environment on the drive, collecting deleted pages for garbage collection on the device for example.
One aim here is to prolong SSD page life by rewriting cell data as infrequently as possible. A single SSD's FTL only knows about the collective state of the cells on that SSD and not their state on other SSDs, which may be better or worse.
Putting a global FTL for all of a server's SSDs in the host OS would enable better optimisation of SSD resources.
Similarly a Shingled Magnetic Recording (SMR) disk drive has sets of partially overlapping write tracks to enable read tracks to be placed on a platter, so increasing the capacity. Compared to a standard, non-SMR drive, the read speed is the same but the write speed is slower as sets (zones) of write tracks have to be rewritten in their entirety to accommodate new data.
The Seagate disk drives manages this task, whereas an HGST SMR implementation has the host manage it. But that HGST SMR translation layer is specific to HGST drives, and can't be assumed to work with Toshiba or Seagate devices.
The Big Blue boffins suggest having a single and global translation layer (TL) software function on a server that can handle SSDS and SMR disk drives and, in fact, any storage media. It sets up a storage resource space where different media has different translation layer functions, such as an SMR one and an SSD FTL one, with load-balancing and media use optimisation.
Incoming read and write IO requests come into this Software Log-Structured Array (SALSA) function and it feeds them to the right translation layer function, called a controller.
The benefits of doing this are listed by the boffins in their paper (PDF) as:
- Achieve substantial performance and durability benefits by implementing the TL on the host for single and multi-device setups. When deploying MySQL database containers on commodity SSDs, SALSA outperforms the raw device by 1:7 on one SSD and by 35:4 on a software RAID-5 array.
- Make efficient use of storage by allowing application-specific policies. They present a SALSA policy tailored to the Swift object store on SMRs that outperforms the raw device by up to a factor of 6:3.
- Decouple space management from storage policy. This enables SALSA to accommodate different applications, each with its own policy, using the same storage pool. This allows running MySQL and Swift on the same storage with high performance and a low overhead.
- Embraces storage diversity by supporting multiple types of devices. They present SALSA can combine SMRs and SSDs to speed up file retrieval for a video server workload (where adding an SSD improves read performance by 19:1), without modifying the application.
They have also written an IBM paper (PDF), which explores SALSA in a more approachable way.
With a MySQL 4-SSD implementation, the system running SALSA on top of the SSDs achieved a 16x higher throughput at about 100ms of transaction response time and a 42x lower transaction response time for a constant throughput of about 50 transactions per sec.
The writers conclude: "SALSA elevates the performance and endurance of commodity Flash-based SSDs to meet the requirements of modern data centres... For host-managed SMR disks, SALSA provides a traditional block interface that hides the complexities of SMR technology from the user, and dramatically improves write performance."
This looks impressive as heck, but who would create SALSA software and ensure it supports actual physical media from suppliers?
WDC could, since it ships both disks and SSDs. IBM might, as it is an OEM customer for disks and SSDs, has written the SALSA paper, and would have the media-level data available to it, as would other storage array and storage server OEMs.
Will they actually do this? Somehow we don't think so, but hope we'll be surprised.
A hyperscaler customer, consuming both SSDs and disks, could do it and may already have done so, but would probably keep the implementation proprietary.
So we think SALSA looks like interesting tech but it isn't going to happen on any significant scale. ®