Linus Torvalds (torvalds@linux-foundation.org) on 1/6/09 wrote:
>
>The only sane flash model is one where the hardware itself
>does the block remapping.
>
>And no, this is not about "most filesystems" or about any
>majority voting. It's a simple technical fact.
>
>The simple fact is that exposing the internal flash
>model to any external software is simply insane. You'd
>never suggest that software should know about the exact
>details of RAM DIMM addressing, and know about open
>pages and the size and organization of banks.
>
>Anybody today realizes that that would be total insanity,
>and that you have a DRAM controller that does all that
>in hardware. Yes, it will have a software component to it
>to set things up, but even that component is effectively
>hidden and done automatically. Not even system software
>really ever needs to know.

Except that certain system software defines constants like L1_CACHE_BYTES. I
wonder what those are all about. ;)

No doubt, devices need some abstraction that is reasonably sane and hides
everything that makes this particular device special. However, I doubt
it makes sense to hide things that are special to every single device - which
would make them rather generic.

Everyone agrees that hard disks are block devices, not byte devices. If you
decided to write byte-aligned to a hard disks, you would get problems as well.
And noone is complaining about those. Limiting the devices to sector-aligned
writes was useful, because it made devices simpler and didn't hurt upper layers
(filesystems, etc.) too much.

Now, if you add further limitations like larger blocks (or sectors if you prefer
a different name) or a requirement for wear leveling of some sort, that may be a
decent tradeoff. It definitely makes life harder on upper layers, particularly
because they have decades of tuning to the hard disk model. But it makes life
simpler for the device. And it may even aid performance.

Of of my main gripes with SSDs is that they are trying to be too smart. If I
write 2k to raw flash, that 2k write is sufficient. If the power fails
immediately after it, the data is still there (ignoring the bogosities of MLC
flash with "paired pages"). Add the controller logic and you either have to
write a full eraseblock for the crap controllers.

Or you have a smarter controller that implements basically a very simple
filesystem (containing exactly one file of fixed size). Now you have to pass
the equivalent of fsync() to the device, which will trigger at least one more
write. Lacking an interface for fsync(), the device has three options that I
can see. Either it conservatively syncs after every single write, and wasts
performance. Or it delays command completion for a while, increasing latency.
Or it tries to second-guess and you occasionally lose data before a power
failure.

And even in the good case, you usually put a filesystem on top of the flash,
which does logical->physical mapping, then pass the data to the controller which
does logical->physical mapping again. And unlike hard disks the mapping is not
n:n in the normal case with a fairly short list of exceptions, but essentially
random.

So my gut feeling is that we can do a better job overall if the SSDs would get
dumber and the storage layer would get smarter. It requires work, no doubt.
But we can do better than the SSD can, because we can avoid double work and have
more information than some SATA device with a 32-entry window of outstanding
requests.

Not that I'd consider UBI a good approach of doing do, mind you.