Subject: Re: Changed mount_mfs behavior?
To: Tld <>
From: Greg A. Woods <>
List: current-users
Date: 09/23/2002 16:53:12
[ On Saturday, September 21, 2002 at 00:47:00 (+0100), Tld wrote: ]
> Subject: Re: Changed mount_mfs behavior?
> Greg A. Woods wrote:
> > IMNSHO that wasn't a terribly "smart" default.  The MFS for /tmp should
> > probably be somewhat smaller than the available swap size, and using the
> > swap size of one partition in one disklabel when you've got many swap
> I don't think so. The addressable space you need is just memory used + mfs 
> space (if we count that as extra).

What about when you try to fill your MFS?  I sure as heck still want a
bit of free swap space when that happens!  In fact I would probably
never make my MFS bigger than 80% of available swap, no matter how much
RAM I have, and with disks these days I still almost always keep at
least twice as much swap around as I have RAM, but not all on one
spindle if I can possibly help it -- I like my swap to be as fast as
possible (though I'm still trying to learn to also keep at least as much
swap on the boot drive's swap partition, which is also dumpdev, as I
have RAM so that it can hold a full crash dump! :-)

> But let me tell you something funny I came accross. :)
> If I have (on a i386 1.6RC1) a mfs /tmp "quite big" (more than phisical 
> RAM, in my case 1024MB), no matter how much swap space I have (in my case, 
> ~1400MB), system will hang as soon as I fill as much space as the free 
> physical RAM. Hard.
> I have tried on just one machine, but might be worth investigating.

See what I mean?  :-)

Seriously though, there have been reports of problems with MFS filling
up (in GNATS PRs even), though I thought they were talking about the
filesystem filling, not the utilisation exceeding available RAM.  Maybe
there's a more subtle relationship than they've noted so far.

I'm sure I've filled an MFS on a machine before, though it may have been
smaller than available RAM.  I don't currently have a machine here with
an MFS /tmp bigger than available RAM, and I'm not sure I want to test
filling even the ones I have without scheduling for potential downtime.  :-)

								Greg A. Woods

+1 416 218-0098;            <>;           <>
Planix, Inc. <>; VE3TCP; Secrets of the Weird <>