Joe “Floid” Kanowitz brought up the idea of RAM being used as disk cache, to which a number of replies were made. I mentioned softupdate snapshots as a possible mechanism, which Sander Vesik corrected to say that it would be more like a “write through” union mount of a MFS and real filesystem.
Kip Macy pointed out that ‘tmpfs‘, on Solaris and Linux does something similar. BSD also has mfs, which requires that you allocate memory ahead of time. (Most commonly used to speed up buildwords in /usr/obj/ .)
The concept of journaling file systems that save the state of a file at given chronological points was brought up, and several people noted ‘Elephant‘. (Link from Hiten Pandya.)
Matt Dillon also wrote up several paragraphs on using RAM for storage, which are sufficiently technical that I’ll paste them in the extended link for this entry, rather then sum up.
(Direct quote follows)
“Well, the existing buffer and path caches are not really well suited to
‘locking’ certain elements into ram. They really wants a ‘backing store’
to play with.
But, that said, it will basically attempt to cache as much as it can in
memory. The two primary limitations which tends to cause cache flushes is
kern.maxvnodes, because in order to flush a vnode the underlying data
cached with that vnode will also be flushed even if memory is available
to hold it, and limitations with the buffer cache.
I believe we could implement a general mechanism to turn off
delayed-writes, write-behind, and other elements on a per-filesystem
basis, and basically revert the associated data from dirty buffer cache
entries to dirty VM pages and then allow them to be paged out on demand
by the VM paging system. This removes the buffer cache limitations
and leaves us only with the vnode limitations.
The MFS filesystem comes fairly close to doing this already since
its backing store is simply the memory associated with a process, but
it has the disadvantage of causing data to be stored in memory twice
(once in the VM / buffer cache, once in the MFS’s procs memory space).
Despite the duplication of data, the fact that MFS filesystems do not
automaticaly flush data to a physical storage device has proven to be
a huge performance advantage over the years.
So, in short, we already have the pieces, we just have to get them to
fit together in a reasonable way.”