Open-Channel SSD Support Still Baking For The Linux Kernel

[phoronix]

Phoronix: Open-Channel SSD Support Still Baking For The Linux Kernel

Matias Bj?rling continues tackling support for "open-channel SSDs" within Linux. His fourth revision to his Open-Channel SSD patch-set has been published and re-based against code in development for the Linux 4.3 kernel...

http://www.phoronix.com/scan.php?page=news_item&px=Open-Channel-SSD-Linux-V4

[s_j_newbury]

This is how SSDs should have always been implemented. SATA/SAS based SSDs are fine for consumer applications, but "Open-Channel" gives so many more opportunities for software optimization, and reduced hardware complexity. No we just need to see some manufacturers come to market with some competitive products...

[AndyChow]

This is how SSDs should have always been implemented. SATA/SAS based SSDs are fine for consumer applications, but "Open-Channel" gives so many more opportunities for software optimization, and reduced hardware complexity. No we just need to see some manufacturers come to market with some competitive products...

It's a horrible idea on all counts. Different NAND needs to be treated differently. Much better to let the manufacturer define their own methods to deal with. I, like 99% of computer users, don't want to start programming my own algorithms for garbage collection, start overprovisionning and make assumptions about NAND error rates, and a wear-leveling strategy.

The same way on a spinning hard-drive, I don't want to tell the hard-drive how to seek the data, where to write it. NCQ is fine, no need to invent my own method.

[s_j_newbury]

It's a horrible idea on all counts. Different NAND needs to be treated differently. Much better to let the manufacturer define their own methods to deal with. I, like 99% of computer users, don't want to start programming my own algorithms for garbage collection, start overprovisionning and make assumptions about NAND error rates, and a wear-leveling strategy.

That's why you use an Operating System.

The same way on a spinning hard-drive, I don't want to tell the hard-drive how to seek the data, where to write it. NCQ is fine, no need to invent my own method.

See here:

http://events.linuxfoundation.org/sites/events/files/slides/LightNVM-Vault2015.pdf

You don't invent your own method unless that's what you really need to do for your specfic application, otherwise you use a logical abstraction:

From the PDF:
How is flash exposed to the host?

? Traditional Flash Translation Layer
? Both metadata and data are managed by the host

? New interfaces
? LUNs (The parallel unit of SSDs)
? Key-value database (e.g. LevelDB and RocksDB)
? Object-store (OSSD)
? Application-driven (New research area)
? File-system (NVMFS)
? Hybrid FTL (Traditional FTL is expensive, offload metadata consistency to device)

? Manage multiple devices under a single address space
? Including garbage collection (Global FTL)

[nils_]

It's a horrible idea on all counts. Different NAND needs to be treated differently. Much better to let the manufacturer define their own methods to deal with. I, like 99% of computer users, don't want to start programming my own algorithms for garbage collection, start overprovisionning and make assumptions about NAND error rates, and a wear-leveling strategy.

You don't have to. Any time data is written you'll be presented with a popup window where you can select the NAND cells where you want to store the data.

[DrYak]

I, like 99% of computer users, don't want to start programming my own algorithms for garbage collection, start overprovisionning and make assumptions about NAND error rates, and a wear-leveling strategy.

You, I and the rest of these 99% aren't the main target for such drives. Probably the main target are the sysadmin at large corporation (imagine Facebook or Google) who'll need to tweak the shit out of their open-channel SSD to milk as much performance as possible for their very specific use (e.g.: their database) with a weird access pattern.

(e.g.: Databases don't play that well with TRIM).

Still there are some useful general use of such technology:

NCQ is fine, no need to invent my own method.

Unlike spinning harddrive, where the firmware has been more or less okay for the past several decades, SSD firmware are still in their infancy, and SSD manufacturer actually do manage to fuck-up support for NCQ.
Just have a look at all the various special case handled by the linux kernel.
e.g.: with the latest firmware some Samsung drives do advertise supporting NCQ together with TRIM but actually dont and corrupt data on disk.

So even if there are part that are more cell technology specific and might not be easy to get, an openchannel SSD is still a chance at eventually debugging and fixing all the general problems (TRIM+NCQ, etc.) that happen for general use user like you and me.

Next to all the specific code (like a special "openchannel SSD" driver for your favorite big SQL database or NoSQL datastore), somebody is bound to develop a translation layer that exposes some kind of "loopback" blockdevice/partition that handles all flash management and can be used in turn with any regular file system. (A little bit like the UBI layer of UBIFS)

(Good if the algo are released as GPL 2 or less, or as BSD and thus could be integrated for firmware for non open-channel variants by SSD manufacturer).

[s_j_newbury]

You, I and the rest of these 99% aren't the main target for such drives. Probably the main target are the sysadmin at large corporation (imagine Facebook or Google) who'll need to tweak the shit out of their open-channel SSD to milk as much performance as possible for their very specific use (e.g.: their database) with a weird access pattern.

(e.g.: Databases don't play that well with TRIM).

Still there are some useful general use of such technology:




Unlike spinning harddrive, where the firmware has been more or less okay for the past several decades, SSD firmware are still in their infancy, and SSD manufacturer actually do manage to fuck-up support for NCQ.
Just have a look at all the various special case handled by the linux kernel.
e.g.: with the latest firmware some Samsung drives do advertise supporting NCQ together with TRIM but actually dont and corrupt data on disk.

So even if there are part that are more cell technology specific and might not be easy to get, an openchannel SSD is still a chance at eventually debugging and fixing all the general problems (TRIM+NCQ, etc.) that happen for general use user like you and me.

Next to all the specific code (like a special "openchannel SSD" driver for your favorite big SQL database or NoSQL datastore), somebody is bound to develop a translation layer that exposes some kind of "loopback" blockdevice/partition that handles all flash management and can be used in turn with any regular file system. (A little bit like the UBI layer of UBIFS)

... and that's what LightNVM is, as in the linked PDF. It's a kernel FTL which exposes the flash devices as one or more block devices. The kernel takes care of the underlying flash management, but in addition to providing regular block devices, it also allows other API possibilities as you've suggested above.

I guess nobody else has picked up on the fact that this technology potentially allows an order of magnitude increase in performance, even before considering application specific strategies. It removes all the bottlenecks from the Flash->FTL->SATA(device)->PCIe->SATA(host)-SATA Driver(OS driver)->block(OS driver) device chain to Flash-PCIe->FTL(LightNVM)->block/other. It's not like this is a new idea, various proprietary implementations of the concept have been deployed for large high performance data systems, it does work, but there was previously no standard.

[DrYak]

I guess nobody else has picked up on the fact that this technology potentially allows an order of magnitude increase in performance, even before considering application specific strategies. It removes all the bottlenecks from the Flash->FTL->SATA(device)->PCIe->SATA(host)-SATA Driver(OS driver)->block(OS driver) device chain to Flash-PCIe->FTL(LightNVM)->block/other. It's not like this is a new idea, various proprietary implementations of the concept have been deployed for large high performance data systems, it does work, but there was previously no standard.

Not to mention processing power: the main CPU has magnitude more omph than the small embed chip on a SSD controller.

It's nearing the same situation as RAID, compression, etc. : It's nice that the controller can do it but at some point, you got to conceed that the main CPU can do it much faster for a ridiculously small penalty. (And unlike some corner case, like the latency constrains of realtime audio mixing, there's practically no drawbacks of doing it on the CPU)

[Ardje]

It's a horrible idea on all counts. Different NAND needs to be treated differently. Much better to let the manufacturer define their own methods to deal with. I, like 99% of computer users, don't want to start programming my own algorithms for garbage collection, start overprovisionning and make assumptions about NAND error rates, and a wear-leveling strategy.

The same way on a spinning hard-drive, I don't want to tell the hard-drive how to seek the data, where to write it. NCQ is fine, no need to invent my own method.

So did you in any way have ever started programming to where your blocks on the hard disk go?

Real developers have been waiting for this. You don't care about what the OS does for you. But kernel developers do. jffs2 and yaffs2 are examples that write on bare nor and nand with wear leveling and hardware ecc when supported. Ubifs and the ubi driver for nand are also meant for bare nand.

FTL layers are only needed for microsoft windows, linux has had enough experience with bare nand. So this is a very good idea. An industry backed standard that removes the complex and often buggy ftl controller, because it wasn't needed after all.

[Lennie]

For those that want to know how flash storage works in practice and what it implies this talk explains a lot:

https://media.ccc.de/browse/congress/2013/30C3_-_5294_-_en_-_saal_1_-_201312291400_-_the_exploration_and_exploitation_of_an_sd_memory_card_-_bunnie_-_xobs.html