Messages in this thread | | | Date | Sat, 26 Jun 1999 09:13:07 -0700 (PDT) | From | Clayton Weaver <> | Subject | raw backing store |
| |
Does anyone (outside of db vendors) implement backing store on a raw partition? What about X-server windows backing store?
I'm wondering what you do if you have 170gb of cheap, 20ns sram-workalike on a chip instead of instead of disks. How do we leverage the efficiency of that in the kernel? Do we still need a filesystem, ie some number of huge ramdisks that are persistent? Or do we just have a database of persistent objects, where a filesystem is just a particular view of it (for the use of legacy software)?
The point is that with that much non-volatile ram, you don't work in ram and then save to backing store, process stack/heap memory and backing store are the same physical bytes. Your disk and ram are indexed by the same vm system. As soon as your code creates a data structure in memory, it's already "saved". A "file" is just a range of bytes in ram, and a directory is just an index of a set of ram objects with the directory/filesystem/partition in common (if one gets rid of files/directories except as an overlay on ram, one still needs partitions to keep runaway software juggernauts from scribbling all over vast amounts of persistent storage, etc).
Do we need to split the kernel into two cooperating processes, one for the fully-persistent processes and the other for transient state like network connections and device interrupts? Otherwise, untangling the transient stuff from the "saved at the point of creation" stuff when the machine is suspended gets hairy (refer all of the past checkpointing discussions). Perhaps just an explicit kernel model of transient vs persistent state would do, ie socket stuff, signals, all of that is in a memory range reserved for the transient parts of processes, that the kernel knows to invalidate and rebuild on a reset or after an apm resume or similar.
This stuff isn't as far away as one might guess, so think about it a little. The filesystem isn't going to need to be able to optimize for seek time on rotating/tape-streamed storage, so forward-looking index designs should be *easily* convertible to what's optimum for a ram instead of a long-latency disk. A filesystem that works best on a ramdisk is going to be ready for the technology when it hits the market.
Regards,
Clayton Weaver <mailto:cgweav@eskimo.com> (Seattle)
"Everybody's ignorant, just in different subjects." Will Rogers
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |