I agree with you, but I understand the other side too.
> But I see absolutely no reason why we should put up with the "hardware"
> actually doing that kind of thing for us, behind our back. And badly.
- Interoperability without losing flexibility.
For a "dumb" block driver to work the translation table must be fixed.
And when running in legacy mode the drive will be very slow. There are
a heap of problems waiting when it gives write access too.
It's very hard to let people switch filesystems. They mostly use the
default one from their OS, or FAT. As long as disks are sold as units
and not as part of a system this will be true.
Having dedicated hardware doing everything is faster and uses less power.
Not talking about an ARM mc, but a custom asic. (Just compare Intel's
SSD idle/active power usage to others.)
- Fast development.
Currently the flash chip interface is standardized with ONFI and the
other end with SATA. All the interesting development happens in-between.
Because it's wedged between stable interfaces it can change a lot without
impacting anything else (except when it's done badly ;-).
So short term the situation is quite hopeless for direct hardware access.
The best hope is probably SSDs with free specifications and open source
Long term I think we should get rid of the notion of a disk and go more
to a model resembling RAM. You could buy arrays of flash and plug them in,
instead of whole disks (they could look like "disks" to the user, but
that's another matter). This decouples the flash from the controller
and makes data recovery easier in case the controller dies.
What is needed is a flash specific interface which replaces SATA and
implements the features that all good flash file systems need: Things
like multi-chip support, ECC handling, background erases and scatter
gather DMA. Perhaps throw in enough support to implement RAID fast
in software, if it makes enough sense. Basically a standardized small,
simple and fast flash controller, preferably accessible via some kind of
host memory interface (PCIe on x86). Make sure to make it flexible enough
to handle things like MRAM/PRAM/FeRAM too.
Maybe AHCI is good enough after a few adaptations, but it can be probably
a lot better. Or perhaps some other interface from the embedded world fits
This will make embedding the controller on a SoC easier too, without the
need for special support in the OS. SATA is really redundant in such cases.
I'm pretty sure most flash controllers already have such chip, but don't
expose it. Instead they hide it behind an embedded microcontroller which
handles SATA and implements the FTL. They should standardize it and get
rid of the power hungry, complexity adding bloat.
I also think it's crucial to get optimal performance, flash gets faster
and faster. It seems pointless to get faster and faster SATA when PCIe
is already fast enough. It's also silly to fake SATA by just implementing
a AHCI controller with direct flash access. Keep SATA around for real
external storage, not something that doesn't take much space anyway.
People that look at SSDs and see them just as disks and don't think about
the future will think it's best if the hardware does as much as possible.
But if you forget the classic disk model and look at what's really going
on it seems obvious that the classic disk model isn't that simple anyway
and doesn't fit flash or how the hardware looks like and could be used.