Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!cmcl2!seismo!mcvax!boring!jack
From: jack@boring.uucp (Jack Jansen)
Newsgroups: net.unix-wizards
Subject: Re: Ram disk with real disk "overflow"
Message-ID: <6882@boring.UUCP>
Date: Mon, 21-Apr-86 08:37:18 EST
Article-I.D.: boring.6882
Posted: Mon Apr 21 08:37:18 1986
Date-Received: Thu, 24-Apr-86 07:16:27 EST
References: <2213@brl-smoke.ARPA> <108@spock.fluke.UUCP>
Reply-To: jack@mcvax.UUCP (Jack Jansen)
Organization: AMOEBA project, CWI, Amsterdam
Lines: 18
Apparently-To: rnews@mcvax


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.