From owner-freebsd-hackers Tue Jan 5 22:16:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA21741 for freebsd-hackers-outgoing; Tue, 5 Jan 1999 22:16:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA21734 for ; Tue, 5 Jan 1999 22:16:08 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id WAA01093; Tue, 5 Jan 1999 22:15:39 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Jan 1999 22:15:39 -0800 (PST) From: Matthew Dillon Message-Id: <199901060615.WAA01093@apollo.backplane.com> To: Brian Dean Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Filesystem overflow ... can it be done? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ( you emailed both -current and -hackers in two separate mails. Please email just one list ). :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 :... : :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 :... : :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 :... :Some of my questions are: : : 1) Can nearly the same results be achieved by dedicating large : amounts of memory for disk buffers? No, not disk buffers. However, if you enable SOFTUPDATES on the hard disk partitions you should get very close to MFS's performance. : 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? If you use MFS, the data is duplicated. There isn't much you can do about it I'm afraid. MFS *is* swap-backed (and will do an even better job after the commits I make after the CVS tree is split), but it is still going to waste memory for active data sets. : 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. Well, I'm sure it's doable, but someone would have to write a filesystem driver to make it work. I wouldn't hold my breath. One thing that will be possible with the MFS commits after the 15th will be creating very large MFS disks and not having 'swap creap' occur when you create and delete large files. MFS is traditionally used on diskless (or low-capacity disk) machines or floppy-boot machines... diskless workstations, essentially. There are certain situations where MFS could very well improve performance - I've used it on sendmail machines to mount sendmail's dns/state cache. But, in general, using SOFTUPDATES and a real disk is going to be much more memory efficient. -Matt :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-hackers" in the body of the message : Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message