4 ms·

one of the fundamental problem with SSDs is the impedance mismatch introduced by emulating HDDs. NVMe doesn't appear to help with that at all we need an interf

by nqzero 12y ago

one of the fundamental problem with SSDs is the impedance mismatch introduced by emulating HDDs. NVMe doesn't appear to help with that at all we need an interface that allows us to bypass the FTL and access the underlying erase blocks

skrause 12y ago
Is there actually any evidence that this would improve performance significantly? Removing the translation layer means that every OS and their file systems have to do good wear leveling because otherwise you'll destroy blocks quickly.
- baruch 12y ago
  It's hard to come up with evidence since there are very few options to create your own SSD/NVMe firmware for a real-world like device. The closest I've come up with is OpenSSD and that required $3000 and was for an old controller with very little documentation behind it.
- chongli 12y ago
  That's pretty easy to do. Just use a log-structured filesystem[0]. The abstraction we use now is antiquated. It's very much reminiscent of the impedance mismatch in graphics APIs (such as OpenGL) which is now being solved (with Vulkan). [0] https://en.wikipedia.org/wiki/Log-structured_file_system https://en.wikipedia.org/wiki/Log-structured_file_system
- justinsb 12y ago
  I think this is the idea behind FusionIO: doing the translation on the host CPU is faster, and allows you to expose additional commands (like atomic writes, or direct key-value interfaces).
deelowe 12y ago
Why?
otterley 12y ago
NVMe is about as simple an interface to a block device as it gets: read blocks, write blocks, and a few health/diagnostic commands. Commands and geometries that originate in spinning disks have been completely extricated. I'm not sure that I'd want the protocol to get involved in the intricacies of backing store housekeeping as you propose. Newer generations of SSDs may not even have erase blocks or translation layers; do we want to have yet another protocol when the technology changes?
- baruch 12y ago
  But these details do matter when you want to achieve maximum performance and they also matter when you want to figure out what went wrong with the device when it fails. The hiding the happens currently in the block interfaces (HDD, SSD & NVMe) definitely allow for easy integration and let things work pretty good for most cases but prevent getting full performance from the device and also obstruct diagnostics when things fail.
pkaye 12y ago
I work on SSD firmware. There is lots of restrictions and algorithms involved with using NAND and presenting a reliable storage to the end user. And many of these algorithms are tuned to the specific NAND. The FTL basically hides the ugly details.
- WeiShi 12y ago
  Can you give some specific restrictions? like sequential page programming in blocks or 'LSB MSB' things?
stellarhopper 12y ago
http://lwn.net/Articles/615341/ http://lwn.net/Articles/615341/

by nqzero 12y ago

skrause 12y ago

Is there actually any evidence that this would improve performance significantly? Removing the translation layer means that every OS and their file systems have to do good wear leveling because otherwise you'll destroy blocks quickly.

baruch 12y ago
It's hard to come up with evidence since there are very few options to create your own SSD/NVMe firmware for a real-world like device. The closest I've come up with is OpenSSD and that required $3000 and was for an old controller with very little documentation behind it.
chongli 12y ago
That's pretty easy to do. Just use a log-structured filesystem[0]. The abstraction we use now is antiquated. It's very much reminiscent of the impedance mismatch in graphics APIs (such as OpenGL) which is now being solved (with Vulkan). [0] https://en.wikipedia.org/wiki/Log-structured_file_system https://en.wikipedia.org/wiki/Log-structured_file_system
justinsb 12y ago
I think this is the idea behind FusionIO: doing the translation on the host CPU is faster, and allows you to expose additional commands (like atomic writes, or direct key-value interfaces).

deelowe 12y ago

Why?

otterley 12y ago

NVMe is about as simple an interface to a block device as it gets: read blocks, write blocks, and a few health/diagnostic commands. Commands and geometries that originate in spinning disks have been completely extricated. I'm not sure that I'd want the protocol to get involved in the intricacies of backing store housekeeping as you propose. Newer generations of SSDs may not even have erase blocks or translation layers; do we want to have yet another protocol when the technology changes?

baruch 12y ago
But these details do matter when you want to achieve maximum performance and they also matter when you want to figure out what went wrong with the device when it fails. The hiding the happens currently in the block interfaces (HDD, SSD & NVMe) definitely allow for easy integration and let things work pretty good for most cases but prevent getting full performance from the device and also obstruct diagnostics when things fail.

pkaye 12y ago

I work on SSD firmware. There is lots of restrictions and algorithms involved with using NAND and presenting a reliable storage to the end user. And many of these algorithms are tuned to the specific NAND. The FTL basically hides the ugly details.

WeiShi 12y ago
Can you give some specific restrictions? like sequential page programming in blocks or 'LSB MSB' things?

stellarhopper 12y ago

http://lwn.net/Articles/615341/ http://lwn.net/Articles/615341/