You raise a good point w.r.t. SSD drives, but the reality is that even if most computers being manufactured today included a solid state drive, the vast majority of consumers are using drives with moving parts. It will be at least a few more generations of hardware before OS-level developers will be able to focus specifically on the features of solid state drives when designing the filesystem and main OS APIs.
That said, there is room for someone to develop a filesystem API designed with solid state in mind, or even an entire OS, but I don't know if there would be enough of a market to make that development worthwhile.
Is there Anything about SSDs that interests you, from the perspective of the future of Redis?
I don't know much about the technical details of JFFS2, only that it takes forever to mount after an unclean shutdown and runs painfully, painfully slow on larger flash volumes (i.e. >512MB) as they approach capacity. I wrote a tutorial (mostly so I could remember how to do it myself) for converting a SheevaPlug from JFFS2 to UBIFS because of the performance difference: http://nitrogen.posterous.com/converting-a-sheevaplug-from-j...
Someone more knowledgable might want to correct me here, but I think JFFS2 arrived a little too early; the performance gains are not enormous and it suffers from too many disadvantages (namely performance with small blocks and apparently determining free space??).
LogFS is yet another file system designed for larger solid state drives (on the order of gigabytes instead of megabytes), and seems to be a step in the right direction. http://en.wikipedia.org/wiki/LogFS
> LogFS stores the inode tree on the drive; JFFS2 does not, which requires it to scan the entire drive at mount and cache the entire tree in RAM. For larger drives, the scan can take tens of seconds and the tree can take a significant amount of main memory.
Interesting. I've only used JFFS2 on embedded systems like OpenWRT routers, where you wouldn't see the large drive penalty.
JFFS2 is intended to be used on raw controller-less flash an thus have to solve many problems that are more efficiently done in hardware. So it's probably only useful in embedded systems. Running normal filesystem on raw flash is good way to make it unusable in few days of light use.
In fact, JFFS2 works by scanning all the storage on mount and having it all in RAM, that causes it's problems with large volumes (slow mounts and also large memory use). In embedded systems, for which it is intended, mounting the volume is rare operation and volumes are generally small, also typical embedded systems running linux has more RAM than Flash.
JFFS(2) is aimed at embedded devices that directly access flash chips. With a controller in between, such as with SSD, which performs wear leveling and other tricks to emulate a real harddrive, it might even be hurtful to performance.
I think you underestimate how serious OS vendors are taking the quickly growing popularity of SSD drives. A lot of work has already been done on OS/filesystem level just for SSD drives, for example to support TRIM.
Sure, it will be a long time (if ever! likely, mechanical drives will remain important for bulk storage) before filesystem developers focus solely on SSD drives, but SSD performance is already very important.
That said, there is room for someone to develop a filesystem API designed with solid state in mind, or even an entire OS, but I don't know if there would be enough of a market to make that development worthwhile.
Is there Anything about SSDs that interests you, from the perspective of the future of Redis?