5 ms·

I'd question could we not use more the powerful, well-cooled, cpu that we already have in our computers instead of pushing the ssd controller complexity and pow

by zokier 3y ago

I'd question could we not use more the powerful, well-cooled, cpu that we already have in our computers instead of pushing the ssd controller complexity and power ever further. What if we used something like UBIFS or F2FS and removed/simplified FTL?

Sakos 3y ago
SSD controllers are just ASICs. I'm not sure why you want to go from a chip tailored for a specific task to a general purpose one that already has way too much on its plate. Then there's things like latency and how the controller abstracts away the details of how an SSD works internally. All that complexity doesn't go away by putting it on your CPU. You're just moving it from one place to another for no benefit, and adding other complexities. Could ask the same thing about all the extra silicon in GPUs that adds hardware acceleration for video encoding/decoding.
- jeffbee 3y ago
  The point of doing it in software on the host kernel would be to allow the flash layer and the filesystem to co-evolve, instead of being agnostic at best and antagonistic at worst.
  - Sakos 3y ago
    Who's going to write the code for it? Microsoft? Does every manufacturer write their own kernel-level driver? What happens to Linux/Unix? I don't want any of these manufacturers anywhere near the kernel, or even doing any more in software than they already do. Samsung isn't exactly known for code quality. This is a fantasy with questionable benefits at best that don't outweigh the downsides.
    - jeffbee 3y ago
      > Microsoft? Yes. That seems ideal to me. Microsoft, Apple, open source contributors. Today what you have is a closed-source translation layer written by the kinds of people who write PC BIOSes, i.e. the biggest idiots in the software industry. I would be much happier with an OS vendor flash storage stack. For all I know, I am already using something like that from Apple. And I assure you that large-scale server builders like Amazon and Google are already doing it this way.
      - mistrial9 3y ago
        calling those layers of people idiots is doing them a favor, excusing the de facto practices as being simply dumb. The truth includes a different layer, the business of business, who pays, who gets to do what. Booting your own hardware is the subject, and the actors there are not the ones that come to mind, thinking of consumer advocacy. The largest companies have other alignments that are not often discussed openly.
    - deleted 3y ago
      [deleted]
    - zokier 3y ago
      > don't want any of these manufacturers anywhere near the kernel, or even doing any more in software than they already do. Samsung isn't exactly known for code quality. That seems such a bizarre take. You think it's better that the crappy code is given to you as blackbox firmware with no oversight rather than in the open written to kernels quality standard where it can at least hypothetically be improved?
    - deleted 3y ago
      [deleted]
phire 3y ago
Once you get to this level of performance, the bulk of a SSD controller ASIC is essentially just high-performance switching fabric; directing the flow of data between the 8-12 channels of NAND flash, the PCIE bus, it's internal buffers and the DRAM. If you have any experience with high performance networking equipment, you know that pure switching fabric ASICs generates a lot of heat on its own. Hell, even a dumb 5-port gigabit ethernet switch generates a surprising amount of heat, they are always warm to the touch. I really doubt that handling the FTL layer on the controller adds that much extra power draw. A dumb PCIE <-> NAND switching ASIC will also have cooling problems.
- trogdor 3y ago
  I recently upgraded my home network to 10 gigabit and was surprised by the amount of heat generated by 10 gig switches. Why do pure switching fabric ASICs generate so much heat?
  - nine_k 3y ago
    Gates consume electricity when they switch: some energy is needed to flip a FET from "open" to "closed" or back. Then the gate stays in a particular state for some time, allowing the circuit to operate. The faster you switch a gate, the more often you have to pay the switching price, which cannot go too low, else the thermal noise would overcome it. So you spend roughly 10x the energy switching a 10 Gbps stream as you use for 1 Gbps stream. Newer, smaller gates consume less energy switching, but not 10x less.
    - deleted 3y ago
      [deleted]
  - hulitu 3y ago
    > Why do pure switching fabric ASICs generate so much heat? There is also the fact that they are consumer devices and margins have to be high so quality of the product is tailored accordingly.
numpad0 3y ago
Speaking from memory and coarse grained understanding, 1) MLC/TLC/QLC work more like 4/8/16-tone grayscale e-paper than flash: e.g. 0x10 = (1,0,1,0), that’s “4 level/bits per cell”. And it’s not a single pulse of 0x10 voltage into a memory cell, more like repetitive pulses from 0b1111 to enough millivolts below 0b1011. Readout is probably more complicated, let alone lifecycle management. Those businesses might be more involved than it’s worth filesystem researchers time. 2) It was often said, at least years ago, that the considerable fraction of heat in NVMe SSDs comes from PCIe serialization/deserialization(SerDes), rather than payload data processing or NAND programming. If both of above are true, maybe it’s PCIe that should be replaced, with something more like the original PCI?
- nine_k 3y ago
  The original PCI was parallel. You can't have an excessively fast parallel bus, because the tiniest differences between lanes make different pins receive the signal out of sync. This is why RAM interface is so hard to get right, and the lanes there are as short as possible.

by zokier 3y ago

Sakos 3y ago

SSD controllers are just ASICs. I'm not sure why you want to go from a chip tailored for a specific task to a general purpose one that already has way too much on its plate. Then there's things like latency and how the controller abstracts away the details of how an SSD works internally. All that complexity doesn't go away by putting it on your CPU. You're just moving it from one place to another for no benefit, and adding other complexities. Could ask the same thing about all the extra silicon in GPUs that adds hardware acceleration for video encoding/decoding.

jeffbee 3y ago
The point of doing it in software on the host kernel would be to allow the flash layer and the filesystem to co-evolve, instead of being agnostic at best and antagonistic at worst.
- Sakos 3y ago
  Who's going to write the code for it? Microsoft? Does every manufacturer write their own kernel-level driver? What happens to Linux/Unix? I don't want any of these manufacturers anywhere near the kernel, or even doing any more in software than they already do. Samsung isn't exactly known for code quality. This is a fantasy with questionable benefits at best that don't outweigh the downsides.
  - jeffbee 3y ago
    > Microsoft? Yes. That seems ideal to me. Microsoft, Apple, open source contributors. Today what you have is a closed-source translation layer written by the kinds of people who write PC BIOSes, i.e. the biggest idiots in the software industry. I would be much happier with an OS vendor flash storage stack. For all I know, I am already using something like that from Apple. And I assure you that large-scale server builders like Amazon and Google are already doing it this way.
    - mistrial9 3y ago
      calling those layers of people idiots is doing them a favor, excusing the de facto practices as being simply dumb. The truth includes a different layer, the business of business, who pays, who gets to do what. Booting your own hardware is the subject, and the actors there are not the ones that come to mind, thinking of consumer advocacy. The largest companies have other alignments that are not often discussed openly.
  - deleted 3y ago
    [deleted]
  - zokier 3y ago
    > don't want any of these manufacturers anywhere near the kernel, or even doing any more in software than they already do. Samsung isn't exactly known for code quality. That seems such a bizarre take. You think it's better that the crappy code is given to you as blackbox firmware with no oversight rather than in the open written to kernels quality standard where it can at least hypothetically be improved?
  - deleted 3y ago
    [deleted]

phire 3y ago

Once you get to this level of performance, the bulk of a SSD controller ASIC is essentially just high-performance switching fabric; directing the flow of data between the 8-12 channels of NAND flash, the PCIE bus, it's internal buffers and the DRAM. If you have any experience with high performance networking equipment, you know that pure switching fabric ASICs generates a lot of heat on its own. Hell, even a dumb 5-port gigabit ethernet switch generates a surprising amount of heat, they are always warm to the touch. I really doubt that handling the FTL layer on the controller adds that much extra power draw. A dumb PCIE <-> NAND switching ASIC will also have cooling problems.

trogdor 3y ago
I recently upgraded my home network to 10 gigabit and was surprised by the amount of heat generated by 10 gig switches. Why do pure switching fabric ASICs generate so much heat?
- nine_k 3y ago
  Gates consume electricity when they switch: some energy is needed to flip a FET from "open" to "closed" or back. Then the gate stays in a particular state for some time, allowing the circuit to operate. The faster you switch a gate, the more often you have to pay the switching price, which cannot go too low, else the thermal noise would overcome it. So you spend roughly 10x the energy switching a 10 Gbps stream as you use for 1 Gbps stream. Newer, smaller gates consume less energy switching, but not 10x less.
  - deleted 3y ago
    [deleted]
- hulitu 3y ago
  > Why do pure switching fabric ASICs generate so much heat? There is also the fact that they are consumer devices and margins have to be high so quality of the product is tailored accordingly.

numpad0 3y ago

Speaking from memory and coarse grained understanding, 1) MLC/TLC/QLC work more like 4/8/16-tone grayscale e-paper than flash: e.g. 0x10 = (1,0,1,0), that’s “4 level/bits per cell”. And it’s not a single pulse of 0x10 voltage into a memory cell, more like repetitive pulses from 0b1111 to enough millivolts below 0b1011. Readout is probably more complicated, let alone lifecycle management. Those businesses might be more involved than it’s worth filesystem researchers time. 2) It was often said, at least years ago, that the considerable fraction of heat in NVMe SSDs comes from PCIe serialization/deserialization(SerDes), rather than payload data processing or NAND programming. If both of above are true, maybe it’s PCIe that should be replaced, with something more like the original PCI?

nine_k 3y ago
The original PCI was parallel. You can't have an excessively fast parallel bus, because the tiniest differences between lanes make different pins receive the signal out of sync. This is why RAM interface is so hard to get right, and the lanes there are as short as possible.