Messages in this thread | | | Date | Sun, 27 Jun 1999 00:48:01 -0700 (PDT) | From | Clayton Weaver <> | Subject | persistent filesystems (right, I forgot the original subject) |
| |
(in re:, multi-gb ram modules instead of hard drives)
The biggest change is probably making the buffer cache a drop-in module that you can enable or disable with a config switch at kernel compile time. If your filesystem is running from non-volatile ram, why do you need a buffer cache? Does the bus make a difference here (main memory bus vs peripheral bus)? Such systems won't need swap, either, if it is on a main memory bus (I've heard 20 ns latency on polymer/silicon hybrid ram; it was 50ns six months ago; it will be cheaper to produce than pure silicon ram and improves the bits per volume by orders of magnitude; don't expect this to not be affordable).
As for the rest of it, a big logical ramdisk is probably the easiest upgrade path (doesn't require changing anything in the filesystem indexing code, that can just be done if it's advantageous to do so). I wonder if we'll need a flag to mmap() to choose "modify in place" or "copy-modify-msync", which means that the change to a file in the second case isn't persistent until the msync().
Working apm code probably handles the persistent process image issues initially, so there should be a fairly smooth upgrade path to leveraging the convenience of cheap giga-ram.
This is simply a hint to not spend immense resources on more intricate buffer cache schemes and seek-optimizing filesystem algorithms, because in the not too distant future those will be non-issues for most systems (network buffering, that's something different of course; maybe a "don't buffer/do buffer" per filesystem granularity will be useful).
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/
| |