Date: Wed, 6 Jan 1999 02:20:19 -0500 (EST) From: Alfred Perlstein <bright@hotjobs.com> To: Brian Dean <brdean@unx.sas.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Filesystem overflow ... can it be done? Message-ID: <Pine.BSF.4.05.9901060215260.37756-100000@bright.fx.genx.net> In-Reply-To: <199901060549.AAA20034@dean.pc.sas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 6 Jan 1999, Brian Dean wrote: > Hi, > > Once a filesystem fills up, is there a way to have it "overflow" into > another filesystem or area of storage? > > I want build a machine whose filesystem is memory-base, i.e., > MFS_ROOT, where root, usr, var, etc, etc, is all memory based. > However, I expect a goodly amount of temporary data to have to be > dealt with in /tmp, but not all of the time. The primary reason for > this is for fast data and program access. The machine could be booted > with a BOOTP kernel, and everything downloaded into it's MFS when it > comes up. > > The problem is that /tmp can fill up at peak times, because I can't > put enough RAM in the machine to cover the expected maximum. I would > be willing to lose performance in this case by having my /tmp overflow > onto disk-based storage when necessary, but I wouldn't want to use > disk storage all the time. > > For a long time now, I've used /tmp as a memory based filesystem, and > the rest of the OS on disk with good performance results. I'd like to > experiment with putting more of my heavily hit code into MFS and maybe > take this to the extreme end of the spectrum of having everything in > MFS, while still leaving enough RAM to run my processes. > > Some of my questions are: > > 1) Can nearly the same results be achieved by dedicating large > amounts of memory for disk buffers? Design and implementation dismisses this idea as a bad one. > > 2) I don't like the idea of consuming RAM with programs in the > MFS, only to get loaded into RAM again to be executed. > Gzipping my executables will help, however, this will > increase the activation time, and I don't want to go to all > this work to have performance lost by decompression. Maybe > the answer to this would be covered in part by the first > question? I'm not sure if MFS uses the text image in memory as the text segment, if it did that would be nice, check the source. gzipping sounds like a bad idea. > > 3) Is this even doable with the filesystem technology in > FreeBSD? A while back I remember discussions about > stackable filesystems which I think might be relevant > here. Sort of, MFS uses swap as a backing store, so with enough swap you can have a LOT of MFS, however be advised that if you run through your MFS data and eat a lot of RAM you'll thrash pretty severly. the only "trick" i could think of was to hook some sort of way of having many vn devices and dynamically adding them to swap (unfortunatly once allocated they can't be free until the machine is rebooted, then the temp files used for swapping can be cleared) -Alfred > > Thanks for any help and suggestions. > > -Brian > -- > Brian Dean Process Engineering brdean@unx.sas.com (x5235) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9901060215260.37756-100000>