jack@boring.uucp (Jack Jansen) (04/21/86)
Something I've been thinking of (but never came around to doing) is to make a device of wich the first bit (say, .5Mb) is RAM disk, and the rest is real disk. The problem with RAM disks is that they're usually small, and you loose big when they run out of space. If you have an overflow capability onto a real disk, there's no problem. The problem with this setup is that you should probably hack the kernel to know that it should try to allocate one of the first 1000 blocks, and only if there aren't any of those, try to allocate one of the other blocks. If you mkfs the disk every time you boot up, you can make this work for a while (by hacking up mkfs a little), but as soon as blocks out on the real disk have been used, they'll show up at the beginning of the freelist and you'll never get rid of them anymore. Comments, anyone? Implementations? -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.
grol@oce-rd3.UUCP (Geert Rolf) (04/23/86)
In article <6882@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) writes: >Something I've been thinking of (but never came around to doing) is to >make a device of wich the first bit (say, .5Mb) is RAM disk, and the >rest is real disk. >The problem with RAM disks is that they're usually small, and you loose >big when they run out of space. If you have an overflow capability onto >a real disk, there's no problem. What do you want, Jack?? Another name/implementation for the disc-cache? Geert R. [don't like oysters; do like shells]
roy@phri.UUCP (Roy Smith) (04/24/86)
In article <6882@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) writes: > Something I've been thinking of (but never came around to doing) is to > make a device of wich the first bit (say, .5Mb) is RAM disk, and the > rest is real disk. How is this any different from just increasing the size of the (already existing) kernel i/o buffer pool? -- Roy Smith, {allegra,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
Unknown@hplabs.UUCP (04/24/86)
This message is empty.
jack@boring.uucp (Jack Jansen) (04/25/86)
In article <347@oce-rd3.UUCP> grol@oce-rd3.UUCP (Geert Rolf) writes: >In article <6882@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) writes: >>Something I've been thinking of (but never came around to doing) is to >>make a device of wich the first bit (say, .5Mb) is RAM disk, and the >>rest is real disk. > >What do you want, Jack?? Another name/implementation for the disc-cache? > The point is, writing data to a real disk will eventually result in a write operation. Even if your buffer cache is big, update will force everything out to disk every minute or so. If you can prevent this, that's nice. This is especially true for files in /tmp. On your average file system, there are about three times as many reads as writes. On /tmp, however, there are 1.2 reads for every write. Another way of achieving more-or-less the same result is giving the buffer cache some knowledge about files (so it doesn't write blocks belonging to files that are gone already). Finding 42 good reasons for not doing this is left to the reader. -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.