Grammar nits. Remove dead words and redundant sentences. Reword a few areas to remove the

'you' which appeared in almost every other line.  One quick markup fix.

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

@@ -24,7 +24,7 @@
       <author>
         <firstname>Matt</firstname>
 	<surname>Dillon</surname>
-	<contrib>Also based on tuning(7) written by </contrib>
+	<contrib>Also based on &man.tuning.7; written by </contrib>
       </author>
     </authorgroup>
   </chapterinfo>
@@ -109,54 +109,43 @@
       <sect3>
 	<title>Base Partitions</title>
 
-	<para>When laying out your filesystem with &man.disklabel.8;
+	<para>When laying out file systems with &man.disklabel.8;
-	  or &man.sysinstall.8;, it is important to remember that hard
+	  or &man.sysinstall.8;, remember that hard
-	  drives can transfer data at a faster rate from the outer
+	  drives transfer data faster from the outer
-	  tracks than the inner.  Knowing this, you should place your
+	  tracks to the inner.
-	  smaller, heavily-accessed filesystems, such as root and
+	  Thus smaller and heavier-accessed file systems
-	  swap, closer to the outside of the drive, while placing
+	  should be closer to the outside of the drive  While
-	  larger partitions, such as <filename>/usr</filename>,
+	  larger partitions like <filename>/usr</filename> should be placed
-	  towards the inner.  To do so, it is a good idea to create
+	  towards the inner.  It is a good idea to create
-	  partitions in a similar order: root, swap,
+	  partitions in a similar order to: root, swap,
 	  <filename>/var</filename>, <filename>/usr</filename>.</para>
 
-	<para>The size of your <filename>/var</filename> partition
+	<para>The size of <filename>/var</filename>
-	  reflects the intended use of your machine.
+	  reflects the intended machine usage.
-	  <filename>/var</filename> is primarily used to hold
+	  <filename>/var</filename> is used to hold
 	  mailboxes, log files, and printer spools.  Mailboxes and log
-	  files, in particular, can grow to unexpected sizes based
+	  files can grow to unexpected sizes depending
-	  upon how many users are on your system and how long your log
+	  on how many users exist and how long log
-	  files are kept.  If you intend to run a mail server, a
+	  files are kept.  Most users would never require a gigabyte,
-	  <filename>/var</filename> partition of over a gigabyte can
+	  but remember that <filename>/var/tmp</filename>
-	  be suitable.  Additionally, <filename>/var/tmp</filename>
+	  must be large enough to contain packages.
-	  must be large enough to contain any packages you may wish to
+	  </para>
-	  add.</para>
 
-	<para>The <filename>/usr</filename> partition holds the bulk
+	<para>The <filename>/usr</filename> partition holds much
-	  of the files required to support the system and a
+	  of the files required to support the system, the &man.ports.7;
-	  subdirectory within it called
+	  collection (recommended) and the source code (optional). Both
-	  <filename>/usr/local</filename> holds the bulk of the files
+	  of which are optional at install time.
-	  installed from the &man.ports.7; hierarchy.  If you do not
+	  At least 2 gigabytes would be recommended for this partition.
-	  use ports all that much and do not intend to keep system
-	  source (<filename>/usr/src</filename>) on the machine, you
-	  can get away with a 1&nbsp;gigabyte <filename>/usr</filename>
-	  partition.  However, if you install a lot of ports
-	  (especially window managers and Linux binaries), we
-	  recommend at least a two gigabyte <filename>/usr</filename>
-	  and if you also intend to keep system source on the machine,
-	  we recommend a three gigabyte <filename>/usr</filename>.  Do
-	  not underestimate the amount of space you will need in this
-	  partition, it can creep up and surprise you!</para>
 
-	<para>When sizing your partitions, keep in mind the space
+	<para>When selecting partition sizes, keep the space
-	  requirements for your system to grow.  Running out of space in
+	  requirements in mind.  Running out of space in
-	  one partition while having plenty in another can lead to much
+	  one partition while barely using another can be a
-	  frustration.</para>
+	  hassle.</para>
 
-	<note><para>Some users who have used &man.sysinstall.8;'s
+	<note><para>Some users have found that &man.sysinstall.8;'s
-	    <literal>Auto-defaults</literal> partition sizer have found
+	    <literal>Auto-defaults</literal> partition sizer will
-	    either their root or <filename>/var</filename> partitions too
+	    sometimes select smaller than adequate <filename>/var</filename>
-	    small later on.  Partition wisely and
+	    and <filename>/</filename> partitions.  Partition wisely and
 	    generously.</para></note>
 
       </sect3>
@@ -167,64 +156,61 @@
 	<indexterm><primary>swap sizing</primary></indexterm>
 	<indexterm><primary>swap partition</primary></indexterm>
 
-	<para>As a rule of thumb, your swap space should typically be
+	<para>As a rule of thumb, the swap partition should be
-	  double the amount of main memory.  For example, if the machine
+	  about double the size of system memory (RAM).  For example, if the machine
 	  has 128&nbsp;megabytes of memory, the swap file should be
-	  256&nbsp;megabytes. Systems with lesser memory may perform better with
+	  256&nbsp;megabytes. Systems with less memory may perform better with
-	  a lot more swap. It is not recommended that you configure any
+	  more swap.
-	  less than 256&nbsp;megabytes of swap on a system and you should
+	  Less than 256&nbsp;megabytes of swap is not recommended and
-	  keep in mind future memory expansion when sizing the swap
+	  memory expansion should be considered.
-	  partition.  The kernel's VM paging algorithms are tuned to
+	  The kernel's VM paging algorithms are tuned to
 	  perform best when the swap partition is at least two times the
 	  size of main memory.  Configuring too little swap can lead to
-	  inefficiencies in the VM page scanning code as well as create
+	  inefficiencies in the VM page scanning code and might create
-	  issues later on if you add more memory to your machine.</para>
+	  issues later if more memory is added.</para>
 
-	<para>Finally, on larger systems with multiple SCSI disks (or
+	<para>On larger systems with multiple SCSI disks (or
 	  multiple IDE disks operating on different controllers), it is
-	  strongly recommend that you configure swap on each drive (up
+	  recommend that a swap is configured on each drive (up
-	  to four drives).  The swap partitions on the drives should be
+	  to four drives).  The swap partitions should be
 	  approximately the same size.  The kernel can handle arbitrary
 	  sizes but internal data structures scale to 4 times the
 	  largest swap partition.  Keeping the swap partitions near the
 	  same size will allow the kernel to optimally stripe swap space
-	  across the disks.  Do not worry about overdoing it a little,
+	  across disks.
-	  swap space is the saving grace of Unix.  Even if you do not
+	  Large swap sizes are fine, regardless if it's not
-	  normally use much swap, it can give you more time to recover
+	  used much.  It might be easier to recover
 	  from a runaway program before being forced to reboot.</para>
       </sect3>
 
       <sect3>
 	<title>Why Partition?</title>
 
-	<para> Why partition at all?  Why not create one big root
+	<para>Several users think a single large partition will be fine,
-	  partition and be done with it?  Then I do not have to worry
+	  but there are several reasons why this is a bad idea.
-	  about undersizing things!</para>
-
-	<para>There are several reasons this is not a good idea.
 	  First, each partition has different operational
-	  characteristics and separating them allows the filesystem to
+	  characteristics and separating them allows the file system to
-	  tune itself to those characteristics.  For example, the root
+	  tune accordingly.  For example, the root
-	  and <filename>/usr</filename> partitions are read-mostly, with
+	  and <filename>/usr</filename> partitions are read-mostly, without
-	  very little writing, while a lot of reading and writing could
+	  much writing.  While a lot of reading and writing could
 	  occur in <filename>/var</filename> and
 	  <filename>/var/tmp</filename>.</para>
 
-	<para>By properly partitioning your system, fragmentation
+	<para>By properly partitioning a system, fragmentation
-	  introduced in the smaller more heavily write-loaded partitions
+	  introduced in the smaller write heavy partitions
 	  will not bleed over into the mostly-read partitions.
-	  Additionally, keeping the write-loaded partitions closer to
+	  Keeping the write-loaded partitions closer to
-	  the edge of the disk, for example before the really big
+	  the disk's edge,
-	  partition instead of after in the partition table, will
+	  will
-	  increase I/O performance in the partitions where you need it
+	  increase I/O performance in the partitions where it occurs
-	  the most.  Now it is true that you might also need I/O
+	  the most.  Now while I/O
-	  performance in the larger partitions, but they are so large
+	  performance in the larger partitions may be needed,
-	  that shifting them more towards the edge of the disk will not
+	  shifting them more towards the edge of the disk will not
-	  lead to a significant performance improvement whereas moving
+	  lead to a significant performance improvement over moving
-	  <filename>/var</filename> to the edge can have a huge impact.
+	  <filename>/var</filename> to the edge.
-	  Finally, there are safety concerns.  Having a small, neat root
+	  Finally, there are safety concerns.  A smaller, neater root
-	  partition that is essentially read-only gives it a greater
+	  partition which is mostly read-only has a greater
-	  chance of surviving a bad crash intact.</para>
+	  chance of surviving a bad crash.</para>
       </sect3>
     </sect2>