1) Return to office.
2) Why we need a dedicated CPU and DRAM attached to flash memory. You can garbage collect and wear level in your OS if you want to. Manufacturers say "no, we have a super secret secret sauce that nobody else could possibly improve upon". Uh huh, sure.
In the spirit of unbridled conspiracy theory (i.e. I have no evidence for this and don't believe it is generally true):
Landlords are paying CxOs kickbacks to push return to office in order to prop up commercial real estate.
Most office buildings are reinforced concrete floors, supported by internal load bearing columns, with glass facings.
... that's exactly the same as a hotel.
Hotels have per-unit bathrooms, typically stacked on top of each other (floor over floor).
Ergo, you can frame out/lose some space to cut several hotel-like vertical utility paths, plumb pipes from them to each floor's bathroom (or HVAC), and Bob's your uncle.
Actual reasons would be things like office floors are built to lower load bearing standards than residential... which I don't believe is true.
[1] https://pdfs.semanticscholar.org/da2d/49a0090e8631ff08eb4813...
[2] https://journals.sagepub.com/doi/pdf/10.1080/004209805003803...
The problem here is that if the CEO sells off the HQ (in a market where everyone has a bunch of unused real estate) they'll almost certainly take a loss (and potentially a loss of billions of dollars, if they e.g. can only sell it for $3B), whereas if they keep it then it's technically valued at what it originally cost to build. The CEO's job is to make the company (look) profitable, so the CEO wants to find any excuse to use the HQ, even if it loses a bit of money or doesn't otherwise make much sense.
For companies that lease, it's the same problem or even worse - corporate office leases tend to be e.g. 3 years, and they're locked into paying actual dollars every quarter until the lease term ends, so if they can't claim to be using the office space then they're directly losing cash. Renegotiating the lease is a bad bet as the landlords have basically zero incentive to do so in the current environment. Thus, they want to appear to use their office space.
There are some other niche benefits too - forcing return to office is a great way to reduce employee count without needing to claim you're downsizing (although if you want to downsize then you can totally make the claim), and it makes office perks more valuable.
There are also some tax breaks from local governments that are contingent on having X number of workers in the office, and WFH could potentially require reversing the tax break.
None of these are "conspiracies", they're just sparkling incentives.
The thing I don't get is, the chips are all commodities, and it's not like soldering them to a board is rocket science. Why isn't one of the companies that makes fully-specified inexpensive RISC-V chips selling one attached to some commodity flash chips and an NVMe connector? Include some minimalist open source firmware that offloads most of the work to the host OS and let the Linux community figure out how to make it better.
At minimum it should allow you to undercut the existing competition on price because you're using a less expensive controller and no DRAM, and in a few years the open source drivers could have enough advantages over black box devices that nobody wants to buy anything else.
Also NAND flash practically requires some sort of error correction system - another thing that fixed function logic in a custom ASIC is very well suited for. Using CPU time on the host CPU for that would probably suck.
Dedicated silicon for error correction might be more efficient, but when there are already fast idle CPU cores it may not matter, and ECC algorithms can already be accelerated by SIMD instructions. Or for high performance machines add the dedicated silicon to the host CPU.
I think even the first step, ie. finding a RISC-V chip that has capability of acting as a PCIe device at all will be a challenge. "Inexpensive" for sure not.
You can get a whole NVMe SSD for $15:
https://www.newegg.com/silicon-power-128gb-p34a60/p/N82E1682...
The hardware required to do this can't be that expensive.
I don't how it is for PCIe, but for example USB is very asymmetric and host controllers generally cannot as devices. There do exist dual-mode IP cores (e.g. for mobile SoCs)
> In any case I would find it hard to believe that the hardware that can act as a device would cost significantly more.
Indeed the area/cost difference between host-only and dual mode controller may be small. But in a general purpose chip there will be dozens of other competiting features in all the other subsystems besides PCIe. Each of those small features would increase the chip cost, so they won't be added without a cost-benefit calculation. So it can still be that while PCIe device support would be cheap to add, it could still be considered too low bang-for-buck to be worth including. Or that there may be such chips supporting PCIe device mode, but they then also would include things like video encoding/decoding, HDMI, ethernet, etc. and thus be an expensive chip.
> The hardware required to do this can't be that expensive.
With a custom ASIC (the linked one seems to have Phison E12) that includes only the minimal needed hardware, yes.
Aren't WD SSDs just that?
Raw NAND comes with various pain-in-the-ass limitations such as: only erasable in huge (~megabytes) blocks at a time, only writable in slightly-uncomfortably-big chunks (like 32KB or so), and erasing a given region can be done a limited amount of times before it breaks. Oh, and all those details (like exact sizes of erases and writes) will change time to time as manufacturing processes of NAND dies get more advanced.
The same goes for network offload features in ethernet controllers, make it an open architecture that you can write your own firmware for.
Meanwhile you could also have drives with offload engines, in the same way that some network cards have offload engines and some don't. But the ones that do are more expensive.
Likewise, some chips could require more error correction because they expect more errors. But the amount of error correction is a tunable in the algorithm; it's a space vs. resilience trade off. Where to set the dial shouldn't be hard to derive from the manufacturer's specifications, or empirical testing if the spec is worthless.
Error correction: Not just amount. What block size? Interleaving? How do you trade overhead due to more ECC vs overhead due to more spare blocks (have to decide how many to allocate up front)? What is the behavior vs temperature and what are you running the thing at?
There has been an ongoing push to standardize NAND interfaces but the controller still needs to know a fair amount about the specific chips it's talking to. I don't know how it will resolve but hopefully the integration becomes more like DRAM where things are a bit more consistent. Then again, if you care a lot about reliability you qualify specific DRAM modules too...
That's not a simple answer but why would it depend on whose chips you have?
> What is the behavior vs temperature and what are you running the thing at?
This is where you might start seeing differences between manufacturers. But this is also optimization. If you don't have this information the chip should still meet a minimum spec and you can use a conservative value. If you do know it you can do something more efficient. And if this becomes popular the chip makers will start publishing what's necessary to do the optimization.
How do you estimate how much life is left on any given part of the physical flash?
This is one of those areas where neglecting the optimizations qualitatively changes the result. It's like Twitter without scalability, sure you can build it in a weekend but what problem does that solve?
Don't get me wrong, I would like to see all of this stuff get better standardized, documented, and open source, but for the most part this is a cost-sensitive commodity and if you want to roll your own SSD qty 1 from bare chips it's just going to be orders of magnitude more expensive than letting SanDisk or whoever do it. Maybe it will be possible to get the hyperscalers and cloud operators to push for the kind of standardization you describe, it would benefit them.
In proportion to how many times it's been rewritten already, or by checking the error rate for what's already written there.
> This is one of those areas where neglecting the optimizations qualitatively changes the result.
It mostly changes how much error correction you have to use. But the nature of it also allows other optimizations.
Suppose you're going to use multi-drive array. Now you could stripe the error correction across devices and use the same system to recover from device failures, which at the same level of total error correction is more resilient.