Date: Thu, 9 Feb 2012 20:11:17 +0100 (CET) From: Niclas Zeising <zeising@daemonic.se> To: FreeBSD-gnats-submit@FreeBSD.org Subject: docs/164938: [PATCH] consistently use file system in config and tuning chapter Message-ID: <201202091911.q19JBHk9063922@vincent.daemonic.se> Resent-Message-ID: <201202091920.q19JK9US093186@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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 @@
<screen>&prompt.root; <userinput>tunefs -n enable /filesystem</userinput>
&prompt.root; <userinput>tunefs -n disable /filesystem</userinput></screen>
- <para>A filesystem cannot be modified with &man.tunefs.8; while
+ <para>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.</para>
@@ -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
- <command>make installworld</command>, 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
+ <command>make installworld</command>, can cause the file system to run
out of space and the update to fail.</para>
<sect3>
@@ -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
<command>rm -r</command>, 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 <command>fsck</command> 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.
</para>
@@ -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.</para>
+ up again, resulting in a fast file system startup.</para>
<para>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 <quote>log
rewind</quote>: 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 <quote>used</quote> which are actually <quote>free</quote>.
&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 <command>mount -f</command>. 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 <emphasis>background fsck</emphasis>: at system startup
time, only a <emphasis>snapshot</emphasis> of the
- filesystem is recorded. The <command>fsck</command> can be
+ file system is recorded. The <command>fsck</command> can be
run later on. All file systems can then be mounted
<quote>dirty</quote>, so the system startup proceeds in
multiuser mode. Then, background <command>fsck</command>s
@@ -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 <quote>older</quote>. In situations where
the standard synchronous approach would have caused some
zero-length files to remain after the
<command>fsck</command>, 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 <command>rm</command>. 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.</para>
</sect3>
--- handbook.config.chapter.sgml.fixes.diff ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201202091911.q19JBHk9063922>