docs/164938: [PATCH] consistently use file system in config and tuning chapter

Niclas Zeising zeising at daemonic.se
Thu Feb 9 19:20:10 UTC 2012


>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 at 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:



More information about the freebsd-doc mailing list