Moving the abstraction to hardware level gets rid of the multi-layer indirections that maps the key-value pairs to actual physical page. It replaces 3 layers of mappings with 1 layer. That reduces CPU load caused by the multi-layer indirections of software KV stores.
You haven't eliminated them. You've just moved them into a dedicated co-processor.
Co-processors are cheap when they're ubiquitous, like DMA. Co-processors are expensive when they're in custom hardware, like K-V stores. I'll get more performance/$ by using standard SSDs than you will by buying specialized hardware. And because the workload is IO dominated, we'll probably both get the same absolute performance from the same server (that differs only in storage devices).
You'll only recoup those CPU cycles back if you bin pack CPU heavy workloads next to IO heavy workloads, which is rarely desirable for storage services, because it adds a great deal of variance. But you just spent shit loads of money eliminating variance by going to SSD.
KV-SSD replaces the filesystem with Abstract Device Interface(ADI), that sits between the KV API exposed to the applications directly and the KV device driver.
According my understanding, although some modern filesystems combines RAID and the file system, these are separate independent abstractions. However, it would be interesting to explore how RAID will work with KV-SSDs. You can take a look at a commercial implementation of Samsung's Mission Peak system to benchmark KV-SSDs (I am not sure whether the following one is an officially approved implementation or not) - https://www.broadberry.com/performance-storage-servers/cyber...
It is accessible directly to applications through the SNIA KVS API (and Samsung has it's own API as well). There is no filesystem in the middle, if you are using the KV-controller.
SNIA KV stack gets rid of the filesystem, and the disk is directly accessible by applications through the API. Hence, it won't be generally useful. The target is a very specific segment of the SSD market.
