Performance advantage, maybe not, but in terms of reliability (which I think for storage devices is far more important than absolute performance) there's definite advantages to having the SSD have its own processor; an SSD is running a realtime control firmware so it can react quickly to events like sudden power loss and act appropriately to flush pending writes and update the BMTs before the power completely dies, whereas the host CPU would basically have no chance at that due to the fact that it's probably doing something else at the time and the latency of communicating to the SSD.

I'm not suggesting the SSD shouldn't have it's own CPU, I'm just suggesting it be dumbed down and not run complex and potentially buggy wear leveling algorithms pushing those up the stack.

Sure, if you never want a drive warranty. Because they'll probably end up blaming your OS for trashing the flash.

So your suggestion for reducing the bugginess of wear-leveling algorithms is to remove them from a dedicated, known-at-compile-time dedicated hardware environment and instead run them on whatever mystery-meat general-purpose stuff the user has?

Can I get a hit off whatever you've got over there? ;)

His suggestion is to not trust random hacked-together-for-a-last-second-release vendor code, and instead use a continuously-developed firmware developed in the open with tests and a broad userbase.

The first rule of hardware is that hardware companies can't write software.

It would actually make quite a bit of sense to just have raw flash accessible by the CPU and be managed completely by it. The problem is then that some of the flash trickery is for very specific flash and requires careful calibration, things like programming time which is per-flash chip and sometimes also changes across time.

The ONFI standard only specifies the protocol and the wiring but not the soft parameters, these may be added in there if people wanted but the flash companies are evidently only trying to grow up into the market rather than just provide building blocks as that allows them to squeeze out more profits so I can't see any incentive by them to expose such an interface and support the ecosystem that will spring up and take all of their extra profits and leave them to build massive foundries for peanuts per unit.

Another reason would be "laziness" of the corporates, there is no real interest in spending lots of time and effort for creating the bottom end parts that may or may not improve the overall system and instead the preference is to build the top-level features and let the ssd vendors deal with the flash itself. Especially when the flash properties change between generations and even in the lifetime of the flash itself. Flash generations also come by very quickly as it is already.

Well you could use these to build a straight passthrough layer, and then work on the file system layer on the host. Probably the easiest way to bootstrap it.

There is probably a benefit in adding some processing on the controller side - eg PCI virtual functions and multiple queues. But mainly you want a block device that reports errors correctly. Not sure where you want to do the error correction (thats like TCP checksum offload, generally done on card vs whole TCP processing).

You would, at minimum, need a new interface framing and command format; as it is, something needs to handle the SATA commands on the other end of the bus and translate them to operate the flash.

This would likely require new interface ICs on motherboards and PCI cards to handle this, either that, or you run everything over USB3.0 (which is only 5GB/s).

Wouldn't that waste a whole lot of CPU cycles? Granted a lot of CPU cycles are just waiting for disk anyway, but directly managing flash would probably distract the CPU from processing data for at least some workloads.

The same argument is used for TCP offload to NICs and from what I've seen it ends up being a bad idea because host CPUs advance much faster than the ones you put in your SSD/NIC/etc. Add to that the fact that you are almost surely leaving optimizations on the table from separating the two layers and I'd very much doubt there would be much performance loss.

And I'd gladly take a performance hit if it meant SSDs become a safe commodity product like hard drives mostly are vs the current situation where a crappy product may very well erase all its data on an unclean shutdown. Manufacturers don't want this of course because there's more margin to be had with the current stuff. Maybe some low end manufacturers could start to implement low-level flash access and Linux using it for the situation to change.

The big pain in such an endeavor is the high cost of an hardware company and the low quantity and the long time it will take to build an ecosystem around such an offering. I'd buy one or a few but beyond the tinkerers there aren't going to be many buyers.

Unless someone of the Google/Facebook clubs will decide it is in their best interest to have such a thing and to enable it to be sold to others as well it is not that likely to happen.

But isn't it the case that Hard Drives have firmware managing most of the "on-drive" behavior?

They manage the hardware bits (rotation speed, head movement, etc) but they don't present much of an abstraction layer over that (they do remap bad blocks). The SSD equivalent would be a firmware that just presents the block structure with wear counters per block and possibly does the read-modify-write dance for writes smaller than a block and remaps broken blocks to a few it keeps hidden. All the other wear leveling stuff it can just let the OS handle.

I'm hoping that efforts like ONFI and UBIFS would bear some fruit, but that does not seem likely. Backwards compatibility seems to trump architectulal elegance almost always.