Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Oct 2005 12:49:32 -0700
From:      David Wolfskill <david@catwhisker.org>
To:        stable@freebsd.org
Subject:   Re: 5.x: how do I get a *swap*-backed /tmp via rc.conf?
Message-ID:  <20051010194932.GT47561@bunrab.catwhisker.org>
In-Reply-To: <200510101103.50546.bkelly@vadev.org>
References:  <20051010020729.GA56351@bunrab.catwhisker.org> <200510110025.34765.malcolm.kay@internode.on.net> <200510101103.50546.bkelly@vadev.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 10, 2005 at 11:03:50AM -0400, Ben Kelly wrote:
> On Monday 10 October 2005 10:55 am, Malcolm Kay wrote:
> ....

> > These paramaters are used by the startup script /etc/rc.d/tmp
> > which calls mount_md defined in /etc/rc.subr which specifically
> > adds the _M (malloc) option to the mdmfs call.
> >
> > You'll need to invoke your own script (or; not so nice;
> > edit rc.subr).
> 
> Is there a reason not to use the ramdisk_* knobs?  This seems to work for me:
> 
> ramdisk_units="10 11"
> 
> # tmp
> ramdisk_10_config="-t swap -s 256m"
> ramdisk_10_perms="1777"
> 
> # mimedefang spool
> ramdisk_11_config="-t swap -s 192m"
> ramdisk_11_owner="mailnull"
> ramdisk_11_perms="700"
>...

Well, other than the point that I'm not seeing those knobs, as
Lowell Gilbert pointed out (in response to my original message),
the "-M" flag was moved from src/etc/rc.subr to the tmpmfs_flags
and varmfs_flags variables in src/etc/defaults/rc.conf in HEAD (on
24 Aug), and that change was MFCed to RELENG_6 on 28 Aug.

I filed a PR, bin/87218 about 3 hours ago, in which I requested
that the change in question also be MFCed to RELENG_5.

I have, in fact, tested the implementation of the change for RELENG_5,
and it both allows the specification of a swap-backed /tmp (while
preserving the default behavior) and when I put the modified RELENG_5
box (with the swap-, rather than malloc-backed /tmp) under a superset of
the load that crashed it yesterday, it performed without a problem.

This would seem to be a Good Thing.  And I don't see a downside to the
requested MFC for RELENG_5.

Peace,
david
-- 
David H. Wolfskill				david@catwhisker.org
Prediction is difficult, especially if it involves the future. -- Niels Bohr

See http://www.catwhisker.org/~david/publickey.gpg for public key.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051010194932.GT47561>