Comment by mastax
3 years ago
You can implement an SSD controller in an FPGA. That's how all the early server SSDs were implemented. I think my Fusion ioScale was one of them.
It's just an enormous amount of effort. This already looks like a huge amount of engineering to do for what must be a very niche product.
Define "an enormous amount of effort" ?
(What one person considers "effort" -- might very well be considered a relaxing and pleasurable and interesting exercise -- by another...
For example, some people hate Math and consider performing Mathematical operations "effort" -- whereas some people love Math and could spend all day at it(!) -- and find the whole process relaxing and stimulating!
It all depends on a given person's interest or disinterest, their affinity or aversion -- to a given line of endeavor...)
So, define "an enormous amount of effort" ?
Point taken, and I expect it's relevant to the author as I doubt even they thought this project was the most monetarily profitable use of their time.
How much effort? I do not know precisely, not having done it before. The relevant NVMe specifications add up to about 1000 pages, which is actually less than I expected. I suspect implementing all of that would take a rather long time regardless, and that's just the host-interface protocols. The harder part, I believe, is the implementation of the controller log itself. I intuit this based on the large visible effort the SSD industry has spent on various hardware and firmware improvements over the last decade. I don't have a good way to summarize it. The question is how much of that effort is necessary when using DRAM rather than NAND? Maybe you don't need sophisticated ECC, bad block detecting, block remapping, garbage collecting, etc.
I am pretty confident, however, that the author knows more about it than I do and their conclusion has been that it's worth using an existing SSD controller.
>I am pretty confident, however, that the author knows more about it than I do and their conclusion has been that it's worth using an existing SSD controller.
When an off-the-shelf SSD controller (as opposed to an FPGA which is much more auditable) is used for a commercial, mass-market SSD -- whoever is making that SSD -- is also putting the root-of-trust for that SSD user's data -- in the hands of the SSD controller manufacturer...
You sure that that SSD controller manufacturer didn't put a hardware backdoor in that SSD controller? You sure that that SSD controller manufacturer didn't embed a hidden "security processor" in the silicon? You sure that it won't covertly communicate your data over RF and/or near-field signals with other nearby similar "black box" electronic components?
Because I'm not!
I wasn't there when the SSD controller was designed, I wasn't there when the SSD controller was fabricated. Any off-the-shelf existing SSD controller is truly a Black Box to me...
Your argument is one of efficiency and expediency.
That's fine for 99% of the Corporations on the planet who value time and efficiency over doing things the harder, slower, less-profitable -- but more correct and ethical transparent way...
My argument is one of transparency, security, knowledge, "doing the homework" -- and understanding how systems truly work under the hood.
Your argument is correct for 99% of the people and corporations out there who value speed and "time-to-market" -- over all other virtues.
But your argument is not correct for 1% of people, and your argument is not correct for me -- for reasons explained above.
In summation, your argument is not wrong...
You are about 99% correct -- but not 100%...
Sure, I could buy a Tesla (or any completely assembled consumer product for that matter!) -- but then I would never have the satisfaction or the fun (or learning!) of trying to build my own! <g>