4 ms·
What's the advantage of this over a simple hardware interface (which should be really simple since I thought NVMe was basically just a PCIe node) that directly
by tenebrisalietum 7y ago
What's the advantage of this over a simple hardware interface (which should be really simple since I thought NVMe was basically just a PCIe node) that directly exposes the flash and then let the application/filesystem/whatever layer handle it?
- Quenty 7y agoThe article explains it. You offload a lot of the processing required by the CPU onto the SSD, and you minimize read writes for the SSD architecture, reducing emulation requirements.
- zzzcpan 7y agoAdding more dedicated hardware that does what you can do on the hardware you already have is not necessarily an advantage.
- amerine 7y agoSpecial purpose silicon is almost always faster and offloading stacks of IO cycles from the main cores is definitely a great thing.
- comboy 7y agoLatency matters. You can execute instructions much faster from firmware on the SSD and higher abstraction level instruction usually translates to many low level instructions.
- brirec 7y agoNot necessarily, but often enough that the most expensive part in a mid range or high end gaming PC is an accelerator card meant to offload certain forms of computation that the CPU can't do as fast... Or perhaps the h.264/h.265 codecs built into modern CPUs and GPUs? And this isn't at all a new phenomenon, either. We've been using accelerators and coprocessors (as they were often originally known) for decades.
- tyingq 7y agoCPU offload. No futzing with blocks. Just send a key and value.
- duskwuff 7y agoNobody wants to deal with raw flash. It's awful. The error rate of raw flash is incredibly high -- it takes loads of error correction to make it reliable, especially with modern MLC and QLC memories -- and the structure of flash erase blocks means that it doesn't support random-access writes. A proper flash translation layer, implemented in hardware, means that software can forget about all the strange features of flash and use it as general-purpose block storage.
- mc32 7y agoAre modern systems much different from the initial M-sys TrueFFS?
- floatboth 7y agoWell, on the other hand, better to have the ability to deal with it rather than have everything obfuscated in unfixable proprietary firmware… https://www.youtube.com/watch?v=fE2KDzZaxvE https://www.youtube.com/watch?v=fE2KDzZaxvE
- tenebrisalietum 7y agoI know how flash works. Linux, for example, supports all the "weirdness" of flash with an MTD module which is low-resource enough for single-core sub 1GHz routers with 16MB and 32MB of RAM to handle. I don't see how that is a burden to a 32-core or higher amd64 architecture CPU in a database server whatsoever. And SSDs already abstract that without adding a key-value store on top of it.
- wtallis 7y ago> Linux, for example, supports all the "weirdness" of flash with an MTD module which is low-resource enough for single-core sub 1GHz routers with 16MB and 32MB of RAM to handle. Managing 16MB of SLC NOR flash is trivial for a 580MHz MIPS core with 32MB of DRAM. Managing 16TB of TLC NAND is completely different. There's a reason that SSDs almost always have 1GB of DRAM for every 1TB of NAND.
- duskwuff 7y agoThe Linux mtd stack is incredibly primitive by today's standards. It's primarily targeted at small SLC flash devices, like the ones you're describing that might be found in a small embedded device, not the large MLC (or beyond) devices that are used in modern storage. It's telling that high-end embedded Linux devices, like Android phones, typically use storage devices which implement their own translation layer, like eMMC or NVMe devices, not raw flash.