Fix the following typos:

metadata     -> meta-data
i-nodes      -> inodes
hierachies   -> hierarchies
i. e.        -> i.e.
soft updates -> Soft Updates

en_US.ISO8859-1/books/handbook/config/chapter.sgml

@@ -907,11 +907,11 @@ kern.maxfiles: 2088 -> 5000</screen>
 	<indexterm><primary>Soft Updates (Details)</primary></indexterm>
 
 	<para>There are two traditional approaches to writing a filesystem's meta-data
-    	  back to disk.  (Metadata updates are updates to
-	  non-content data like i-nodes or directories.)</para>
+    	  back to disk.  (Meta-data updates are updates to
+	  non-content data like inodes or directories.)</para>
 	
 	<para>Historically, the default behaviour was to write out
-	  metadata updates synchronously.  If a directory had been
+	  meta-data updates synchronously.  If a directory had been
 	  changed, the system waited until the change was actually
 	  written to disk.  The file data buffers (file contents) were
 	  passed through the buffer cache and backed up
@@ -931,23 +931,23 @@ kern.maxfiles: 2088 -> 5000</screen>
 	  to the disk.  This includes updates to the directory itself,
 	  to the i-node table, and possibly to indirect blocks
 	  allocated by the file.  Similar considerations apply for
-	  unrolling large hierachies (<command>tar -x</command>).</para>
+	  unrolling large hierarchies (<command>tar -x</command>).</para>
 
 	<para>The second case is asynchronous meta-data updates.  This
   	  is the default for Linux/ext2fs and
   	  <command>mount -o async</command> for *BSD ufs.  All
-  	  metadata updates are simply being passed through the buffer
+  	  meta-data updates are simply being passed through the buffer
   	  cache too, that is, they will be intermixed with the updates
   	  of the file content data.  The advantage of this
   	  implementation is there is no need to wait until each
-  	  metadata update has been written to disk, so all operations
-  	  which cause huge amounts of metadata updates work much
+  	  meta-data update has been written to disk, so all operations
+  	  which cause huge amounts of meta-data updates work much
   	  faster than in the synchronous case.  Also, the
   	  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
-  	  that updated large amounts of metadata (like a power
+  	  that updated large amounts of meta-data (like a power
   	  failure, or someone pressing the reset button),
 	  the file system
   	  will be left in an unpredictable state.  There is no opportunity
@@ -976,18 +976,18 @@ kern.maxfiles: 2088 -> 5000</screen>
 	  than synchronous updates.
 	  Additionally the complexity of the implementation is fairly
 	  limited, so the risk of bugs being present is low.  A disadvatage
-	  is that all metadata are written twice (once into the
+	  is that all meta-data are written twice (once into the
 	  logging region and once to the proper location) so for
 	  normal work, a performance <quote>pessimization</quote>
 	  might result.  On the other hand, in case of a crash, all
-	  pending metadata operations can be quickly either rolled-back
+	  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>
      
 	<para>Kirk McKusick, the developer of Berkeley FFS,
 	   solved this problem with Soft Updates: all pending
-	   metadata updates are kept in memory and written out to disk
-	   in a sorted sequence (<quote>ordered metadata
+	   meta-data updates are kept in memory and written out to disk
+	   in a sorted sequence (<quote>ordered meta-data
 	   updates</quote>).  This has the effect that, in case of
 	   heavy meta-data operations, later updates to an item
 	   <quote>catch</quote> the earlier ones if the earlier ones are still in
@@ -995,14 +995,14 @@ kern.maxfiles: 2088 -> 5000</screen>
 	   operations on, say, a directory are generally performed in
 	   memory before the update is written to disk (the data
 	   blocks are sorted according to their position so
-	   that they will not be on the disk ahead of their metadata).
+	   that they will not be on the disk ahead of their meta-data).
 	   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
 	   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 i-nodes.
+	   are marked as such in their appropriate bitmaps: blocks and inodes.
 	   After a crash, the only resource allocation error
 	   that occurs is that resources are
 	   marked as <quote>used</quote> which are actually <quote>free</quote>.
@@ -1020,13 +1020,13 @@ kern.maxfiles: 2088 -> 5000</screen>
 	   multiuser mode.  Then, background <command>fsck</command>s
 	   will be scheduled for all filesystems where this is required, to free
 	   resources that may be unused.  (Filesystems that do not use
-	   soft updates still need the usual foreground
+	   Soft Updates still need the usual foreground
 	   <command>fsck</command> though.)</para>
 
-	 <para>The advantage is that metadata operations are nearly as
-	   fast as asynchronous updates (i. e. faster than with
+	 <para>The advantage is that meta-data operations are nearly as
+	   fast as asynchronous updates (i.e. faster than with
 	   <emphasis>logging</emphasis>, which has to write the
-	   metadata twice).  The disadvantages are the complexity of
+	   meta-data twice).  The disadvantages are the complexity of
 	   the code (implying a higher risk for bugs in an area that
 	   is highly sensitive regarding loss of user data), and a
 	   higher memory consumption.  Additionally there are some
@@ -1036,7 +1036,7 @@ kern.maxfiles: 2088 -> 5000</screen>
 	   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 metadata
+	   with a Soft Updates filesystem 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