From owner-freebsd-current@FreeBSD.ORG Thu Jun 1 11:59:20 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A473116A799 for ; Thu, 1 Jun 2006 11:59:20 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id CED1243D48 for ; Thu, 1 Jun 2006 11:59:18 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from gothmog.pc (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.6/8.13.6/Debian-1) with ESMTP id k51BwxND013278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Jun 2006 14:59:01 +0300 Received: from gothmog.pc (gothmog [127.0.0.1]) by gothmog.pc (8.13.6/8.13.6) with ESMTP id k51C1Cqi005525; Thu, 1 Jun 2006 15:01:12 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from giorgos@localhost) by gothmog.pc (8.13.6/8.13.6/Submit) id k51C1B6C005524; Thu, 1 Jun 2006 15:01:11 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Thu, 1 Jun 2006 15:01:11 +0300 From: Giorgos Keramidas To: Jonathan Noack Message-ID: <20060601120111.GA5507@gothmog.pc> References: <20060522211223.GA3621@xor.obsecurity.org> <20060522231437.GC1446@odin.ac.hmc.edu> <20060523133037.GA2908@gothmog.pc> <20060523143013.GA11472@ci0.org> <20060523194106.GA46634@xor.obsecurity.org> <20060524203645.GB13500@gothmog.pc> <20060524203747.GA88742@xor.obsecurity.org> <20060524204617.GA13701@gothmog.pc> <20060601002024.GA1453@gothmog.pc> <447E7540.8070904@alumni.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <447E7540.8070904@alumni.rice.edu> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.408, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.79, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-current@FreeBSD.org, Kris Kennaway Subject: Re: md /tmp and async mounts X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2006 11:59:22 -0000 On 2006-06-01 01:04, Jonathan Noack wrote: > On 05/31/06 20:20, Giorgos Keramidas wrote: > > The following diff should be sufficient for enabling -o async for > > the MFS /tmp and MFS /var filesystems we support in our current > > rc.d stuff: > > > > %%% > > Index: share/man/man5/rc.conf.5 > > =================================================================== > > --- share/man/man5/rc.conf.5 (revision 99) > > +++ share/man/man5/rc.conf.5 (revision 101) > > @@ -24,7 +24,7 @@ > > .\" > > .\" $FreeBSD: src/share/man/man5/rc.conf.5,v 1.298 2006/05/30 16:20:48 matteo Exp $ > > .\" > > -.Dd May 29, 2006 > > +.Dd Jun 1, 2006 > > .Dt RC.CONF 5 > > .Os > > .Sh NAME > > @@ -241,12 +241,13 @@ > > .Pa /tmp > > is created. > > The default is > > -.Dq Li "-S -M" , > > +.Dq Li "-S -M -o async" , > > which inhibits the use of softupdates on > > .Pa /tmp > > to waste as little space as possible > > -and creates a pure memory backed disk, which will never be swapped out, > > -for maximum performance and system stability at low memory conditions. > > +and creates a pure memory-backed disk, which uses asynchronous I/O > > +and will never be swapped out, for maximum performance and system > > +stability at low memory conditions. > > Given recent posts about panics with malloc-backed mds under > low-memory conditions (see the "kmem leak in tmpmfs?" thread on > stable@), I'm not sure keeping '-M' as the default for tmpmfs > and varmfs is advisable. Here is the rather ominous note on > using malloc-backed mds in mdconfig(8): "Storage for this type > of memory disk is allocated with malloc(9). This limits the > size to the malloc bucket limit in the kernel. If the -o > reserve option is not set, creating and filling a large > malloc-backed memory disk is a very easy way to panic a > system." Note that the -M option has *been* already the default for ages. I am not suggestting to change these options in this patch.