From darklogik@pittgoth.com  Fri Jan 18 07:25:26 2002
Return-Path: <darklogik@pittgoth.com>
Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111])
	by hub.freebsd.org (Postfix) with ESMTP id 0ED1037B405
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 18 Jan 2002 07:25:25 -0800 (PST)
Received: (from darklogik@localhost)
	by pittgoth.com (8.11.6/8.11.6) id g0IFQWu67068;
	Fri, 18 Jan 2002 10:26:32 -0500 (EST)
	(envelope-from darklogik)
Message-Id: <200201181526.g0IFQWu67068@pittgoth.com>
Date: Fri, 18 Jan 2002 10:26:32 -0500 (EST)
From: Tom Rhodes <darklogik@pittgoth.com>
Reply-To: Tom Rhodes <darklogik@pittgoth.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: [PATCH] Kernel Config Chapter, not 4.5 ready
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         34036
>Category:       docs
>Synopsis:       [PATCH] Kernel Config Chapter, not 4.5 ready
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-doc
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jan 18 07:30:00 PST 2002
>Closed-Date:    Mon Jan 21 10:17:25 PST 2002
>Last-Modified:  Mon Jan 21 10:20:34 PST 2002
>Originator:     
>Release:        FreeBSD 5.0-CURRENT i386
>Organization:
>Environment:
System: FreeBSD localhost 5.0-CURRENT

>Description:
As talked about with a few project members, and mainly under the direction of RWatson, I have added
some of the new features of the 4.5 GENERIC kernel to the handbook.  This is not all of the options, but it
will add the options SOFTUPDATES and the kern.maxusers information.  It will also reword a previous sentence
that I thought difficult to understand :)

>How-To-Repeat:
Look at both, 4.5 GENERIC and the handbook kernel config chapter

>Fix:
Apply this diff, I will provide more to the chapter later on :)






*** chapter.sgml.old	Thu Jan 17 21:16:28 2002
--- chapter.sgml	Thu Jan 17 23:48:53 2002
***************
*** 503,524 ****
        <secondary>maxusers</secondary>
      </indexterm>
  
!     <programlisting>maxusers          32</programlisting>
  
!     <para>The <literal>maxusers</literal> option sets the size of a number
!       of important system tables.  This number is supposed to be roughly
        equal to the number of simultaneous users you expect to have on your
!       machine.  However, under normal circumstances, you will want to set
!       <literal>maxusers</literal> to at least 4, especially if you are
!       using the X Window System or compiling software.  The reason is that
!       the most important table set by <literal>maxusers</literal> is the
!       maximum number of processes,  which is set to <literal>20 + 16 *
!       maxusers</literal>, so if you set <literal>maxusers</literal> to 1,
!       then you can only have 36 simultaneous processes, including the 18
!       or so that the system starts up at boot time, and the 15 or so you
!       will probably create when you start the X Window System.  Even a
!       simple task like reading a manual page will start up nine processes to
!       filter, decompress, and view it.  Setting
        <literal>maxusers</literal> to 64 will allow you to have up to 1044
        simultaneous processes, which should be enough for nearly all uses.
        If, however, you see the dreaded <errortype>proc table
--- 503,533 ----
        <secondary>maxusers</secondary>
      </indexterm>
  
!     <programlisting>maxusers          0</programlisting>
  
!     <para>The <literal>maxusers</literal> option will set the size for many
!       important system tables.  This number is supposed to be roughly
        equal to the number of simultaneous users you expect to have on your
!       machine.  Since 4.5-RELEASE, however, the <literal>maxusers</literal>
!       option is auto-tuning, and set at 0 by default in the configuration.
!       Using a value of 0 will let the system automatically select the
!       appropriate value based on physical system memory.
!       This value can be obtained after booting, by looking at
!       <literal>kern.maxusers</literal>, and modified at boot-time by changing the
!       <filename>kernel</filename> configuration, or just by updating
!       <literal>kern.maxusers</literal> in the <filename>/boot/loader.conf</filename>
!       file.  Using a value other than 0, will cause the <filename>kernel</filename>
!       to use the old style <literal>maxusers</literal>, and it is
!       recommended you set this value no less than 4 if you wish to manually
!       enter it, specially if you will be using the X Window System or compiling
!       software.  The reason for this is that the most important table set by
!       <literal>maxusers</literal> is the maximum number of processes,
!       which is set to <literal>20 + 16 * maxusers</literal>, so if you set
!       <literal>maxusers</literal> to 1, then you can only have 36 simultaneous
!       processes, including the 18 or so that the system starts up at boot
!       time, and the 15 or so you will probably create when you start the X
!       Window System.  Even a simple task like reading a manual page will start
!       up nine processes to filter, decompress, and view it.  Setting
        <literal>maxusers</literal> to 64 will allow you to have up to 1044
        simultaneous processes, which should be enough for nearly all uses.
        If, however, you see the dreaded <errortype>proc table
***************
*** 677,682 ****
--- 686,705 ----
        -C</command>, which will display any <command>write</command>,
        <command>talk</command>, and any other messages you receive, as well
        as any console messages sent by the kernel.</para>
+ 
+     <programlisting>options	     SOFTUPDATES         #Softupdates</programlisting>
+ 
+     <para>This options allows for faster dist writing.</para>
+ 
+       <note>
+         <para><option>SOFTUPDATES</option> are already enabled in the
+         <filename>GENERIC</filename> kernel, but they are not turned on
+ 	by default.  You need to set this option yourself using the
+ 	&man.tunefs.8; command, and specifying the <option>-n</option>
+ 	option.  Please read over the
+ 	<filename>/usr/src/sys/ufs/ffs/README.softupdates</filename> file before
+ 	setting this option</para>
+       </note>
  
      <programlisting>options          USERCONFIG          #boot -c editor</programlisting>
  
>Release-Note:
>Audit-Trail:

From: Ceri <setantae@submonkey.net>
To: Tom Rhodes <darklogik@pittgoth.com>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: docs/34036: [PATCH] Kernel Config Chapter, not 4.5 ready
Date: Fri, 18 Jan 2002 16:18:31 +0000

 On Fri, Jan 18, 2002 at 10:26:32AM -0500, Tom Rhodes wrote:
 
 > +     <para>This options allows for faster dist writing.</para>
 
 s/dist/disk/
 
 > +         <para><option>SOFTUPDATES</option> are already enabled in the
 
 Did I hear someone say on -doc earlier this week that SoftUpdates is to be
 considered singular ?
 
 > +         <filename>GENERIC</filename> kernel, but they are not turned on
 > + 	by default.  You need to set this option yourself using the
 > + 	&man.tunefs.8; command, and specifying the <option>-n</option>
 > + 	option.
 
 Could also mention newfs -U ?
 
 Ceri

From: Tom Rhodes <darklogik@pittgoth.com>
To: FreeBSD-gnats-submit <FreeBSD-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: docs/34036: [PATCH] Kernel Config Chapter, not 4.5 ready
Date: Fri, 18 Jan 2002 11:31:16 -0500

 I am sorry, but I have noticed a slight mistake in my patch, on the line under
 
 options SOFTUPDATES, I typed "dist" instead of "disk" I apologize for 
 that mistake and I will be a tad bit more careful on the next!
 
 Also, I have dabbed into GENERIC a bit more, and noticed that options 
 UFS_DIRHASH is listed, but not all togeather.  For instance, GENERIC 
 says that the option speeds up performance on big directories, but makes 
 no note on the fact that, the performance is uses ram for this, a 
 machine with a small amount of ram may not want that option listed.  I 
 will make a note of that on my next kernel patch.
 
 
 > + 
 > +     <programlisting>options	     SOFTUPDATES         #Softupdates</programlisting>
 > + 
 > +     <para>This options allows for faster dist writing.</para>
 > + 
 > +       <note>
 > +         <para><option>SOFTUPDATES</option> are already enabled in the
 > +         <filename>GENERIC</filename> kernel, but they are not turned on
 > + 	by default.  You need to set this option yourself using the
 > + 	&man.tunefs.8; command, and specifying the <option>-n</option>
 > + 	option.  Please read over the
 > + 	<filename>/usr/src/sys/ufs/ffs/README.softupdates</filename> file before
 > + 	setting this option</para>
 > +       </note>
 >   
 >       <programlisting>options          USERCONFIG          #boot -c editor</programlisting>
 
 
 -- 
 Tom (Darklogik) Rhodes
 www.Pittgoth.com Gothic Liberation Front
 www.FreeBSD.org  The Power To Serve
 

From: Tom Rhodes <darklogik@pittgoth.com>
To: Ceri <setantae@submonkey.net>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: docs/34036: [PATCH] Kernel Config Chapter, not 4.5 ready
Date: Fri, 18 Jan 2002 11:40:41 -0500

 Ceri wrote:
 
 > On Fri, Jan 18, 2002 at 10:26:32AM -0500, Tom Rhodes wrote:
 > 
 > 
 >>+     <para>This options allows for faster dist writing.</para>
 >>
 > 
 > s/dist/disk/
 > 
 
 
 I was one step ahead or behind you, right before I obtained your email, 
 I sent a reply to my patch pointing this out :)
 
 > 
 >>+         <para><option>SOFTUPDATES</option> are already enabled in the
 >>
 > 
 > Did I hear someone say on -doc earlier this week that SoftUpdates is to be
 > considered singular ?
 
 
 I sup'd the source yesterday to verify that (I remember something along 
 that line) but in my 4.5 GENERIC file, it is listed as plural, and it 
 builds fine without modification, so I just left it be :)
 
 > 
 > 
 >>+         <filename>GENERIC</filename> kernel, but they are not turned on
 >>+ 	by default.  You need to set this option yourself using the
 >>+ 	&man.tunefs.8; command, and specifying the <option>-n</option>
 >>+ 	option.
 >>
 > 
 > Could also mention newfs -U ?
 > 
 > Ceri
 > 
 Thanks for pointing out the -U option, but isn't that for a NEW filesystem?
 
 
 #man 8 newfs
 <snip>
 -U   Enables soft updates on the new filesystem
 
 I can understand pointing this out, but that is with a new filesystem, 
 and figured a need to only point out how to enable softupdates, I 
 suppose adding a &man.newfs.8 wouldn't hurt at all though :)
 
 At least I can be sure that more people are paying attention to me than 
 what credit I give hehehe
 
 
 -- 
 Tom (Darklogik) Rhodes
 www.Pittgoth.com Gothic Liberation Front
 www.FreeBSD.org  The Power To Serve
 

From: Ceri <setantae@submonkey.net>
To: Tom Rhodes <darklogik@pittgoth.com>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: docs/34036: [PATCH] Kernel Config Chapter, not 4.5 ready
Date: Sat, 19 Jan 2002 10:38:30 +0000

 On Fri, Jan 18, 2002 at 11:40:41AM -0500, Tom Rhodes wrote:
 > Ceri wrote:
 > >On Fri, Jan 18, 2002 at 10:26:32AM -0500, Tom Rhodes wrote:
 > >
 > >>+         <para><option>SOFTUPDATES</option> are already enabled in the
 > >
 > >Did I hear someone say on -doc earlier this week that SoftUpdates is to be
 > >considered singular ?
 > 
 > I sup'd the source yesterday to verify that (I remember something along 
 > that line) but in my 4.5 GENERIC file, it is listed as plural, and it 
 > builds fine without modification, so I just left it be :)
 
 I meant more as in :
 	<para><option>SOFTUPDATES</option> is already enabled ....
 
 > >Could also mention newfs -U ?
 > >
 > Thanks for pointing out the -U option, but isn't that for a NEW filesystem?
 
 Certainly is, yes.
 
 > I can understand pointing this out, but that is with a new filesystem, 
 > and figured a need to only point out how to enable softupdates, I 
 > suppose adding a &man.newfs.8 wouldn't hurt at all though :)
 
 I reckon; I find it a lot less hassle to just do :
 	newfs -U /dev/whatever
 than:
 	newfs /dev/whatever && tunefs -n enable /dev/whatever
 
 Laziness _is_ a virtue :)
 
 Ceri

From: Tom Rhodes <darklogik@pittgoth.com>
To: Ceri <setantae@submonkey.net>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: docs/34036: [PATCH] Kernel Config Chapter, not 4.5 ready
Date: Sun, 20 Jan 2002 23:19:51 -0500

 Ceri wrote:
 
 >On Fri, Jan 18, 2002 at 11:40:41AM -0500, Tom Rhodes wrote:
 >
 >>Ceri wrote:
 >>
 >>>On Fri, Jan 18, 2002 at 10:26:32AM -0500, Tom Rhodes wrote:
 >>>
 >>>>+         <para><option>SOFTUPDATES</option> are already enabled in the
 >>>>
 >>>Did I hear someone say on -doc earlier this week that SoftUpdates is to be
 >>>considered singular ?
 >>>
 >>I sup'd the source yesterday to verify that (I remember something along 
 >>that line) but in my 4.5 GENERIC file, it is listed as plural, and it 
 >>builds fine without modification, so I just left it be :)
 >>
 >
 >I meant more as in :
 >	<para><option>SOFTUPDATES</option> is already enabled ....
 >
 >>>Could also mention newfs -U ?
 >>>
 >>Thanks for pointing out the -U option, but isn't that for a NEW filesystem?
 >>
 >
 >Certainly is, yes.
 >
 >>I can understand pointing this out, but that is with a new filesystem, 
 >>and figured a need to only point out how to enable softupdates, I 
 >>suppose adding a &man.newfs.8 wouldn't hurt at all though :)
 >>
 >
 >I reckon; I find it a lot less hassle to just do :
 >	newfs -U /dev/whatever
 >than:
 >	newfs /dev/whatever && tunefs -n enable /dev/whatever
 >
 >Laziness _is_ a virtue :)
 >
 >Ceri
 >
 >
 More or less depends on how you set up your hard drive though, I would 
 not recommend you play around with newfs on a /usr partition :) 
  Thinking that most users would already have their system setup before 
 compiling a kernel was the idea in mind when I wrote this, and that they 
 would also enable softupdates on current partitions.  I suppose, 
 however, a man link or quick info line would not hurt one bit, should I 
 submit another patch or just revise the section if/when this is commited?
 
 
 --Tom Rhodes
 
 
State-Changed-From-To: open->closed 
State-Changed-By: keramida 
State-Changed-When: Mon Jan 21 10:17:25 PST 2002 
State-Changed-Why:  
Tmo, who submitted this, has told me in private mail he's got another 
patch coming, and will file a new PR when it is ready. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=34036 
>Unformatted:
