From owner-freebsd-doc@FreeBSD.ORG Wed Aug 4 17:20:09 2004 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93B9C16A4D0 for ; Wed, 4 Aug 2004 17:20:09 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AC8643D58 for ; Wed, 4 Aug 2004 17:20:09 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i74HK9DN010460 for ; Wed, 4 Aug 2004 17:20:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i74HK9UV010456; Wed, 4 Aug 2004 17:20:09 GMT (envelope-from gnats) Resent-Date: Wed, 4 Aug 2004 17:20:09 GMT Resent-Message-Id: <200408041720.i74HK9UV010456@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Marju Ignatjeva Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 480EB16A4CE for ; Wed, 4 Aug 2004 17:19:31 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A2B243D2F for ; Wed, 4 Aug 2004 17:19:31 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.12.11/8.12.11) with ESMTP id i74HJUgd097507 for ; Wed, 4 Aug 2004 17:19:30 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.12.11/8.12.11/Submit) id i74HJU9q097502; Wed, 4 Aug 2004 17:19:30 GMT (envelope-from nobody) Message-Id: <200408041719.i74HJU9q097502@www.freebsd.org> Date: Wed, 4 Aug 2004 17:19:30 GMT From: Marju Ignatjeva To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: docs/70005: [PATCH] Contradictory section in Handbook(config) at 11.12.1.1 vfs.vmiodirenable - proposal to change wording X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2004 17:20:09 -0000 >Number: 70005 >Category: docs >Synopsis: [PATCH] Contradictory section in Handbook(config) at 11.12.1.1 vfs.vmiodirenable - proposal to change wording >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Wed Aug 04 17:20:09 GMT 2004 >Closed-Date: >Last-Modified: >Originator: Marju Ignatjeva >Release: 4.8-RELEASE >Organization: http://www.bsd.ee >Environment: FreeBSD localhost 4.8-RELEASE FreeBSD 4.8-RELEASE #0: Tue Jun 8 20:54:08 EEST 2004 marju@localhost:/usr/src/sys/compile/MINUKERNEL i386 >Description: There is a contradictory section in the Handbook's Configuration and Tuning chapter, at 11.12.1.1 vfs.vmiodirenable If you look at how that section has been changed, you'll see that the default value of the variable is now 1, however the text keeps talking about _turning on_ that variable. I created a patch, shown below in the 'Fix to the problem' box. Here follows an illustration to my problem: RCS file: /usr/local/www/cvsroot/FreeBSD/doc/en_US.ISO8859-1/books/handbook/config/chapter.sgml,v retrieving revision 1.1 retrieving revision 1.162 diff -u -p -r1.1 -r1.162 --- doc/en_US.ISO8859-1/books/handbook/config/chapter.sgml 2001/07/10 02:33:49 1.1 +++ doc/en_US.ISO8859-1/books/handbook/config/chapter.sgml 2004/07/28 09:14:23 1.162 @@ -1,160 +1,216 @@ + + vfs.vmiodirenable + + The vfs.vmiodirenable sysctl variable - defaults to 0 (off) (though soon it will default to 1) and may - be set to 0 (off) or 1 (on). This parameter controls how - directories are cached by the system. Most directories are - small and use but a single fragment (typically 1K) in the - filesystem and even less (typically 512 bytes) in the buffer - cache. However, when operating in the default mode the buffer + may be set to either 0 (off) or 1 (on); it is 1 by default. + This variable controls how directories are cached by the + system. Most directories are small, using just a single + fragment (typically 1 K) in the file system and less + (typically 512 bytes) in the buffer cache. + However, when operating in the default mode the buffer cache will only cache a fixed number of directories even if you have a huge amount of memory. Turning on this sysctl allows the buffer cache to use the VM Page Cache to cache the - directories. >How-To-Repeat: diff the initial revision against the current one... http://www.freebsd.org/cgi/cvsweb.cgi/doc/en_US.ISO8859-1/books/handbook/config/chapter.sgml >Fix: I created a patch with some rearrangements as to the wording and here is my diff with that patch against revision 1.161: eiland>diff -u r1.161 conf.fix --- r1.161 Mon Jul 26 18:06:41 2004 +++ conf.fix Mon Jul 26 18:12:22 2004 @@ -1566,18 +1566,18 @@ system. Most directories are small, using just a single fragment (typically 1 K) in the file system and less (typically 512 bytes) in the buffer cache. - However, when operating in the default mode the buffer + With this variable turned off (to 0), the buffer cache will only cache a fixed number of directories even if - you have a huge amount of memory. Turning on this sysctl + you have a huge amount of memory. When turned on (to 1), this sysctl allows the buffer cache to use the VM Page Cache to cache the directories, making all the memory available for caching directories. However, the minimum in-core memory used to cache a directory is the physical page size (typically 4 K) rather than 512  - bytes. We recommend turning this option on if you are running + bytes. We recommend keeping this option on if you are running any services which manipulate large numbers of files. Such services can include web caches, large mail systems, and news - systems. Turning on this option will generally not reduce + systems. Keeping on this option will generally not reduce performance even with the wasted memory but you should experiment to find out. >Release-Note: >Audit-Trail: >Unformatted: