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.

So, this was not entirely intuitive to me, but you make a compelling argument that since the kernel can't know as much about the storage medium as the disk controller does, it's best to leave all the low-level optimizations to the storage controller and have a simple backwards compatible interface (i.e. just LBAs and sectors) between the disk and the host controllers.

I'd like to ask, how much SSD knowledge do you think the upper layers of the storage stack should have ? things such as:

* Making sure that the FS aligns data blocks (I'm thinking about the 4k blocks in an ext2 fs) such that no data block goes across an erase region boundary (this will also be important with spinning disks in the future when they do away with 512 byte sectors...)

* Possible FS data placement optimizations to try to have files fit in a single erase block, similar to what's being done with stride/stripe mke2fs options when using RAID

* Maybe having the disk scheduler spend less effort trying to reduce seeks, and more effort trying to reduce the number of erase blocks being written to - for example, when one write request will cause a given erase block to be written to, maybe the disk scheduler could try to find any dirty buffers within that same erase block that have not been scheduled for writing yet, and try to 'eagerly' write them in the hope that they won't be dirtied again ???

* The ext2 optimizations that split inode tables into many small subtables, each close to their data blocks, in order to reduce seeks, seem quite pointless on SSD

My point is, even though spinning disks use a simple LBA/sector type of interface, there is still a lot of knowledge in upper layers about the kinds of latencies that are expected. We've not seen similar upper-layer optimizations for SSD yet, and I wonder if that's coming, or do you think that the SSD controller should try to hide all these aspects as well ???