Attachment 121866 Details for Bug 164938 – handbook.config.chapter.sgml.fixes.diff

[patch] handbook.config.chapter.sgml.fixes.diff

handbook.config.chapter.sgml.fixes.diff (text/plain), 6.73 KB, created by Niclas Zeising on 2012-02-09 19:20:09 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Niclas Zeising

Created: 2012-02-09 19:20:09 UTC

Size: 6.73 KB

patch

obsolete

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

Actions: View | Diff

Attachments on bug 164938: 121866