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:
parent
57737501c3
commit
d98f23f2d2
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=14488
1 changed files with 67 additions and 81 deletions
|
@ -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 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 megabytes of memory, the swap file should be
|
||||
256 megabytes. Systems with lesser memory may perform better with
|
||||
a lot more swap. It is not recommended that you configure any
|
||||
less than 256 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 megabytes. Systems with less memory may perform better with
|
||||
more swap.
|
||||
Less than 256 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>
|
||||
|
||||
|
|
Loading…
Reference in a new issue