diff --git a/en_US.ISO8859-1/books/handbook/config/chapter.sgml b/en_US.ISO8859-1/books/handbook/config/chapter.sgml
index 08f9463f1c..ae66aae91a 100644
--- a/en_US.ISO8859-1/books/handbook/config/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/config/chapter.sgml
@@ -940,18 +940,18 @@ kern.maxfiles: 2088 -> 5000</screen>
   	  metadata 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's no need to wait until each
+  	  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
   	  faster than in the synchronous case.  Also, the
-  	  implementation is still clear and simple, so there's a low
+  	  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
   	  failure, or someone pressing the reset button),
 	  the file system
-  	  will be left in an unpredictable state.  There's no chance
+  	  will be left in an unpredictable state.  There is no chance
   	  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 i-node
@@ -996,7 +996,7 @@ kern.maxfiles: 2088 -> 5000</screen>
 	   operations on, say, a directory are generally done still in
 	   memory before the update is written to disk (the data
 	   blocks are sorted to their according position as well so
-	   that they won't be on the disk ahead of their metadata).
+	   that they will not be on the disk ahead of their metadata).
 	   In case of a crash 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
@@ -1017,7 +1017,7 @@ kern.maxfiles: 2088 -> 5000</screen>
 	   time, only a <emphasis>snapshot</emphasis> from the
 	   filesystem is recorded, that <command>fsck</command> can be
 	   run against later on.  All filesystems can then be mounted
-	   <quote> dirty</quote>, and system startup proceeds to
+	   <quote>dirty</quote>, and system startup proceeds to
 	   multiuser mode.  Then, background <command>fsck</command>s
 	   will be scheduled for all filesystems that need it, to free
 	   up possibly unused resources.  (Filesystems that do not use
@@ -1043,7 +1043,7 @@ kern.maxfiles: 2088 -> 5000</screen>
 	   not instantly available but only after the updates have
 	   written to disk.  This can in particular cause problems
 	   when installing large amounts of data into a filesystem
-	   that doesn't have enough free space to hold all the files
+	   that does not have enough free space to hold all the files
 	   twice.</para>
       </sect3>
     </sect2>