On 2006-06-01 01:04, Jonathan Noack <noackjr_at_alumni.rice.edu> 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) > > _at__at_ -24,7 +24,7 _at__at_ > > .\" > > .\" $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 > > _at__at_ -241,12 +241,13 _at__at_ > > .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_at_), 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.Received on Thu Jun 01 2006 - 09:59:20 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:56 UTC