Although many of the problems (i.e. seek time) of rotating disks are overcome by solid state persistent memory, you still need special datastructures to ensure that:
a) data is buffered during write and that a power failure won't leave the storage in an inconsistent state
b) blocks to be overwritten are reallocated and erased in background (you cannot simply overwrite a flash block before erasing it)
c) the used datastructures (trees etc) are optimized for the size of the flash block
d) gracefully handle block corruption
Since it should be possible to remap blocks (either because of (b) or corruption (d)) it's common to have a logical block remapping layer somewhere in the (disk) controller. At this point classical filesystem algorithms and datastructure can easily solve the remaining problems (consistency with journaling and block optimized access like on rotating disks).
Of course, there is another approach for solving (b): see http://en.wikipedia.org/wiki/Log-structured_file_system
(actually, log structured filesystem technique can be used to implement the block remapping within the ssd compatibility layer which lies inside the disk controller itself, but that's a detail)
or copy on write filesystems like zfs/btrfs etc (although AFAIK they rely on a disk interface which is compatible to a rotating disk).
That's to say that solid state storage is not really just persistent ram where you can apply the same datastructures and procedures you would use in core.
Future technologies might be different and trim down these differences so that you could really have huge amount of super fast word addressable random memory access, where nothing can be lost even in case of power failure. But, even assuming that this might be possible, it's possible that later there will be yet another technology with even better storage density/ cost but which will introduce back some of the complications. So, it's understandable why you want to keep some abstractions, so that you can easily replace the underlying technologies and get most of the benefits.
a) data is buffered during write and that a power failure won't leave the storage in an inconsistent state b) blocks to be overwritten are reallocated and erased in background (you cannot simply overwrite a flash block before erasing it) c) the used datastructures (trees etc) are optimized for the size of the flash block d) gracefully handle block corruption
Since it should be possible to remap blocks (either because of (b) or corruption (d)) it's common to have a logical block remapping layer somewhere in the (disk) controller. At this point classical filesystem algorithms and datastructure can easily solve the remaining problems (consistency with journaling and block optimized access like on rotating disks).
Of course, there is another approach for solving (b): see http://en.wikipedia.org/wiki/Log-structured_file_system (actually, log structured filesystem technique can be used to implement the block remapping within the ssd compatibility layer which lies inside the disk controller itself, but that's a detail) or copy on write filesystems like zfs/btrfs etc (although AFAIK they rely on a disk interface which is compatible to a rotating disk).
That's to say that solid state storage is not really just persistent ram where you can apply the same datastructures and procedures you would use in core.
Future technologies might be different and trim down these differences so that you could really have huge amount of super fast word addressable random memory access, where nothing can be lost even in case of power failure. But, even assuming that this might be possible, it's possible that later there will be yet another technology with even better storage density/ cost but which will introduce back some of the complications. So, it's understandable why you want to keep some abstractions, so that you can easily replace the underlying technologies and get most of the benefits.