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.
This commit is contained in:
Tom Rhodes 2002-10-05 02:15:42 +00:00
parent 57737501c3
commit d98f23f2d2
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=14488

View file

@ -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;
or &man.sysinstall.8;, it is important to remember that hard
drives can transfer data at a faster rate from the outer
tracks than the inner. Knowing this, you should place your
smaller, heavily-accessed filesystems, such as root and
swap, closer to the outside of the drive, while placing
larger partitions, such as <filename>/usr</filename>,
towards the inner. To do so, it is a good idea to create
partitions in a similar order: root, swap,
<para>When laying out file systems with &man.disklabel.8;
or &man.sysinstall.8;, remember that hard
drives transfer data faster from the outer
tracks to the inner.
Thus smaller and heavier-accessed file systems
should be closer to the outside of the drive While
larger partitions like <filename>/usr</filename> should be placed
towards the inner. It is a good idea to create
partitions in a similar order to: root, swap,
<filename>/var</filename>, <filename>/usr</filename>.</para>
<para>The size of your <filename>/var</filename> partition
reflects the intended use of your machine.
<filename>/var</filename> is primarily used to hold
<para>The size of <filename>/var</filename>
reflects the intended machine usage.
<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
upon how many users are on your system and how long your log
files are kept. If you intend to run a mail server, a
<filename>/var</filename> partition of over a gigabyte can
be suitable. Additionally, <filename>/var/tmp</filename>
must be large enough to contain any packages you may wish to
add.</para>
files can grow to unexpected sizes depending
on how many users exist and how long log
files are kept. Most users would never require a gigabyte,
but remember that <filename>/var/tmp</filename>
must be large enough to contain packages.
</para>
<para>The <filename>/usr</filename> partition holds the bulk
of the files required to support the system and a
subdirectory within it called
<filename>/usr/local</filename> holds the bulk of the files
installed from the &man.ports.7; hierarchy. If you do not
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>The <filename>/usr</filename> partition holds much
of the files required to support the system, the &man.ports.7;
collection (recommended) and the source code (optional). Both
of which are optional at install time.
At least 2 gigabytes would be recommended for this partition.
<para>When sizing your partitions, keep in mind the space
requirements for your system to grow. Running out of space in
one partition while having plenty in another can lead to much
frustration.</para>
<para>When selecting partition sizes, keep the space
requirements in mind. Running out of space in
one partition while barely using another can be a
hassle.</para>
<note><para>Some users who have used &man.sysinstall.8;'s
<literal>Auto-defaults</literal> partition sizer have found
either their root or <filename>/var</filename> partitions too
small later on. Partition wisely and
<note><para>Some users have found that &man.sysinstall.8;'s
<literal>Auto-defaults</literal> partition sizer will
sometimes select smaller than adequate <filename>/var</filename>
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
double the amount of main memory. For example, if the machine
<para>As a rule of thumb, the swap partition should be
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
a lot more swap. It is not recommended that you configure any
less than 256&nbsp;megabytes of swap on a system and you should
keep in mind future memory expansion when sizing the swap
partition. The kernel's VM paging algorithms are tuned to
256&nbsp;megabytes. Systems with less memory may perform better with
more swap.
Less than 256&nbsp;megabytes of swap is not recommended and
memory expansion should be considered.
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
issues later on if you add more memory to your machine.</para>
inefficiencies in the VM page scanning code and might create
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
to four drives). The swap partitions on the drives should be
recommend that a swap is configured on each drive (up
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,
swap space is the saving grace of Unix. Even if you do not
normally use much swap, it can give you more time to recover
across disks.
Large swap sizes are fine, regardless if it's not
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
partition and be done with it? Then I do not have to worry
about undersizing things!</para>
<para>There are several reasons this is not a good idea.
<para>Several users think a single large partition will be fine,
but there are several reasons why this is a bad idea.
First, each partition has different operational
characteristics and separating them allows the filesystem to
tune itself to those characteristics. For example, the root
and <filename>/usr</filename> partitions are read-mostly, with
very little writing, while a lot of reading and writing could
characteristics and separating them allows the file system to
tune accordingly. For example, the root
and <filename>/usr</filename> partitions are read-mostly, without
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
introduced in the smaller more heavily write-loaded partitions
<para>By properly partitioning a system, fragmentation
introduced in the smaller write heavy partitions
will not bleed over into the mostly-read partitions.
Additionally, keeping the write-loaded partitions closer to
the edge of the disk, for example before the really big
partition instead of after in the partition table, will
increase I/O performance in the partitions where you need it
the most. Now it is true that you might also need I/O
performance in the larger partitions, but they are so large
that shifting them more towards the edge of the disk will not
lead to a significant performance improvement whereas moving
<filename>/var</filename> to the edge can have a huge impact.
Finally, there are safety concerns. Having a small, neat root
partition that is essentially read-only gives it a greater
chance of surviving a bad crash intact.</para>
Keeping the write-loaded partitions closer to
the disk's edge,
will
increase I/O performance in the partitions where it occurs
the most. Now while I/O
performance in the larger partitions may be needed,
shifting them more towards the edge of the disk will not
lead to a significant performance improvement over moving
<filename>/var</filename> to the edge.
Finally, there are safety concerns. A smaller, neater root
partition which is mostly read-only has a greater
chance of surviving a bad crash.</para>
</sect3>
</sect2>