From owner-freebsd-doc@FreeBSD.ORG Thu Feb 9 19:20:10 2012 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DCF11065677 for ; Thu, 9 Feb 2012 19:20:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D68CE8FC12 for ; Thu, 9 Feb 2012 19:20:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q19JK98k093187 for ; Thu, 9 Feb 2012 19:20:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q19JK9US093186; Thu, 9 Feb 2012 19:20:09 GMT (envelope-from gnats) Resent-Date: Thu, 9 Feb 2012 19:20:09 GMT Resent-Message-Id: <201202091920.q19JK9US093186@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, Niclas Zeising Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E46431065675 for ; Thu, 9 Feb 2012 19:11:25 +0000 (UTC) (envelope-from zeising@daemonic.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 70A758FC13 for ; Thu, 9 Feb 2012 19:11:25 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id BB57C40007 for ; Thu, 9 Feb 2012 20:11:24 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id B0E6240009; Thu, 9 Feb 2012 20:11:24 +0100 (CET) Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 02CF340007 for ; Thu, 9 Feb 2012 20:11:24 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id C4781119C1B for ; Thu, 9 Feb 2012 20:11:23 +0100 (CET) Received: from mx.daemonic.se ([IPv6:2001:470:dca9:0:1::3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [2001:470:dca9:0:1::6]) (amavisd-new, port 10025) with ESMTPS id 2rfXdqt2smhj for ; Thu, 9 Feb 2012 20:11:17 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 5F8AC119C17 for ; Thu, 9 Feb 2012 20:11:17 +0100 (CET) Received: from vincent.daemonic.se (login.daemonic.se [IPv6:2001:470:dca9:0:1::10]) by mail.daemonic.se (Postfix) with ESMTPS id 4BF0212B20D for ; Thu, 9 Feb 2012 20:11:17 +0100 (CET) Received: (from zeising@localhost) by vincent.daemonic.se (8.14.5/8.14.5/Submit) id q19JBHk9063922; Thu, 9 Feb 2012 20:11:17 +0100 (CET) (envelope-from zeising) Message-Id: <201202091911.q19JBHk9063922@vincent.daemonic.se> Date: Thu, 9 Feb 2012 20:11:17 +0100 (CET) From: Niclas Zeising To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: docs/164938: [PATCH] consistently use file system in config and tuning chapter X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Niclas Zeising List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 19:20:10 -0000 >Number: 164938 >Category: docs >Synopsis: [PATCH] consistently use file system in config and tuning chapter >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: Thu Feb 09 19:20:09 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Niclas Zeising >Release: FreeBSD 9.0-BETA2 amd64 >Organization: >Environment: System: FreeBSD vincent.daemonic.se 9.0-BETA2 FreeBSD 9.0-BETA2 #0 r225368: Sat Sep 3 22:13:26 CEST 2011 root@vincent.daemonic.se:/usr/obj/usr/src/sys/VINCENT amd64 >Description: In the configuration and tuning chapter of the handbook, both "filesystem" and "file system" are used. >How-To-Repeat: >Fix: Attached patch updates the chapter to consistently use "file system", since this seems to be the most common in the English version of the handbook. --- handbook.config.chapter.sgml.fixes.diff begins here --- Index: en_US.ISO8859-1/books/handbook/config/chapter.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/config/chapter.sgml,v retrieving revision 1.250 diff -u -d -r1.250 chapter.sgml --- en_US.ISO8859-1/books/handbook/config/chapter.sgml 31 Jan 2012 14:14:59 -0000 1.250 +++ en_US.ISO8859-1/books/handbook/config/chapter.sgml 9 Feb 2012 19:06:45 -0000 @@ -1926,7 +1926,7 @@ &prompt.root; tunefs -n enable /filesystem &prompt.root; tunefs -n disable /filesystem - A filesystem cannot be modified with &man.tunefs.8; while + A file system cannot be modified with &man.tunefs.8; while it is mounted. A good time to enable Soft Updates is before any partitions have been mounted, in single-user mode. @@ -1934,13 +1934,13 @@ file creation and deletion, through the use of a memory cache. We recommend to use Soft Updates on all of your file systems. There are two downsides to Soft Updates that you should be aware of: First, - Soft Updates guarantees filesystem consistency in the case of a crash + Soft Updates guarantees file system consistency in the case of a crash but could very easily be several seconds (even a minute!) behind updating the physical disk. If your system crashes you may lose more work than otherwise. Secondly, Soft Updates delays the freeing of - filesystem blocks. If you have a filesystem (such as the root - filesystem) which is almost full, performing a major update, such as - make installworld, can cause the filesystem to run + file system blocks. If you have a file system (such as the root + file system) which is almost full, performing a major update, such as + make installworld, can cause the file system to run out of space and the update to fail. @@ -1968,7 +1968,7 @@ or not at all. If the data blocks of a file did not find their way out of the buffer cache onto the disk by the time of the crash, &man.fsck.8; is able to recognize this and - repair the filesystem by setting the file length to + repair the file system by setting the file length to 0. Additionally, the implementation is clear and simple. The disadvantage is that meta-data changes are slow. An rm -r, for instance, touches all the files @@ -1992,19 +1992,19 @@ implementation is still clear and simple, so there is a low risk for bugs creeping into the code. The disadvantage is that there is no guarantee at all for a consistent state of - the filesystem. If there is a failure during an operation + the file system. If there is a failure during an operation that updated large amounts of meta-data (like a power failure, or someone pressing the reset button), - the filesystem + the file system will be left in an unpredictable state. There is no opportunity - to examine the state of the filesystem when the system + to examine the state of the file system when the system comes up again; the data blocks of a file could already have been written to the disk while the updates of the inode table or the associated directory were not. It is actually impossible to implement a fsck which is able to clean up the resulting chaos (because the necessary information is not available on the disk). If the - filesystem has been damaged beyond repair, the only choice + file system has been damaged beyond repair, the only choice is to use &man.newfs.8; on it and restore it from backup. @@ -2028,7 +2028,7 @@ might result. On the other hand, in case of a crash, all pending meta-data operations can be quickly either rolled-back or completed from the logging area after the system comes - up again, resulting in a fast filesystem startup. + up again, resulting in a fast file system startup. Kirk McKusick, the developer of Berkeley FFS, solved this problem with Soft Updates: all pending @@ -2045,7 +2045,7 @@ If the system crashes, this causes an implicit log rewind: all operations which did not find their way to the disk appear as if they had never happened. A - consistent filesystem state is maintained that appears to + consistent file system state is maintained that appears to be the one of 30 to 60 seconds earlier. The algorithm used guarantees that all resources in use are marked as such in their appropriate bitmaps: blocks and inodes. @@ -2054,13 +2054,13 @@ marked as used which are actually free. &man.fsck.8; recognizes this situation, and frees the resources that are no longer used. It is safe to - ignore the dirty state of the filesystem after a crash by + ignore the dirty state of the file system after a crash by forcibly mounting it with mount -f. In order to free resources that may be unused, &man.fsck.8; needs to be run at a later time. This is the idea behind the background fsck: at system startup time, only a snapshot of the - filesystem is recorded. The fsck can be + file system is recorded. The fsck can be run later on. All file systems can then be mounted dirty, so the system startup proceeds in multiuser mode. Then, background fscks @@ -2077,17 +2077,17 @@ is highly sensitive regarding loss of user data), and a higher memory consumption. Additionally there are some idiosyncrasies one has to get used to. - After a crash, the state of the filesystem appears to be + After a crash, the state of the file system appears to be somewhat older. In situations where the standard synchronous approach would have caused some zero-length files to remain after the fsck, these files do not exist at all - with a Soft Updates filesystem because neither the meta-data + with a Soft Updates file system because neither the meta-data nor the file contents have ever been written to disk. Disk space is not released until the updates have been written to disk, which may take place some time after running rm. This may cause problems - when installing large amounts of data on a filesystem + when installing large amounts of data on a file system that does not have enough free space to hold all the files twice. --- handbook.config.chapter.sgml.fixes.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: