Date: Tue, 5 Jun 2001 00:05:51 -0400 (EDT) From: tadayuki@mediaone.net To: FreeBSD-gnats-submit@freebsd.org Subject: docs/27885: tuning(7) has some misspelling Message-ID: <200106050405.f5545pb18885@localhost.isi.com>
next in thread | raw e-mail | index | archive | help
>Number: 27885
>Category: docs
>Synopsis: tuning(7) has some misspelling
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-doc
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: doc-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Jun 04 21:10:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator: Tadayuki OKADA
>Release: FreeBSD 4.3-STABLE i386
>Organization:
>Environment:
System: FreeBSD photoniii 4.3-STABLE FreeBSD 4.3-STABLE #26: Sat Jun 2 15:54:54 EDT 2001 root@photoniii:/usr/obj/usr/src/sys/PHOTON i386
>Description:
I found some misspelling in tuning(7). A patch included.
By the way, as of todays STABLE, IDE write caching is the default again.
Shouldn't the description be changed?
About softupdate, I read a mail which shows softupdates slows down
interactive operation and I think it's correct.
Is it worth a mention?
# English is not my native language, forgive me if I made a mistake.
>How-To-Repeat:
>Fix:
--- tuning.7.orig Mon Jun 4 22:29:50 2001
+++ tuning.7 Mon Jun 4 23:21:34 2001
@@ -16,7 +16,7 @@
.Xr disklabel 8
to lay out your filesystems on a hard disk it is important to remember
that hard drives can transfer data much more quickly from outer tracks
-then they can from inner tracks. To take advantage of this you should
+than they can from inner tracks. To take advantage of this you should
try to pack your smaller filesystems and swap closer to the outer tracks,
follow with the larger filesystems, and end with the largest filesystems.
It is also important to size system standard filesystems such that you
@@ -116,7 +116,7 @@
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 significnat
+them more towards the edge of the disk will not lead to a significant
performance improvement whereas moving /var 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
@@ -159,7 +159,7 @@
recovery times after a crash. Do not use this option
unless you are actually storing large files on the partition, because if you
overcompensate you can wind up with a filesystem that has lots of free
-space remaining but cannot accomodate any more files. Using
+space remaining but cannot accommodate any more files. Using
32768, 65536, or 262144 bytes/inode is recommended. You can go higher but
it will have only incremental effects on fsck recovery times. For
example,
@@ -187,10 +187,10 @@
Softupdates drastically improves meta-data performance, mainly file
creation and deletion. We recommend turning softupdates on on all of your
filesystems. There are two downsides to softupdates that you should be
-aware of: First, softupdates guarentees filesystem consistency in the
+aware of: First, softupdates guarantees filesystem consistency in the
case of a crash but could very easily be several seconds (even a minute!)
behind updating the physical disk. If you crash you may lose more work
-then otherwise. Secondly, softupdates delays the freeing of filesystem
+than otherwise. Secondly, softupdates delays the freeing of filesystem
blocks. If you have a filesystem (such as the root filesystem) which is
close to full, doing a major update of it, e.g.
.Em make installworld,
@@ -209,11 +209,11 @@
time. You should only stripe partitions that require serious I/O performance...
typically /var, /home, or custom partitions used to hold databases and web
pages. Choosing the proper stripe size is also
-important. Filesystems tend to store meta-data on power-of-2 boundries
-and you usually want to reduce seeking rather then increase seeking. This
+important. Filesystems tend to store meta-data on power-of-2 boundaries
+and you usually want to reduce seeking rather than increase seeking. This
means you want to use a large off-center stripe size such as 1152 sectors
so sequential I/O does not seek both disks and so meta-data is distributed
-across both disks rather then concentrated on a single disk. If
+across both disks rather than concentrated on a single disk. If
you really need to get sophisticated, we recommend using a real hardware
raid controller from the list of
.Fx
@@ -249,7 +249,7 @@
the VM Page Cache to cache the directories. The advantage is that all of
memory is now available for caching directories. The disadvantage is that
the minimum in-core memory used to cache a directory is the physical page
-size (typically 4K) rather then 512 bytes. We recommend turning this option
+size (typically 4K) rather than 512 bytes. We recommend turning this option
on if you are running any services which manipulate large numbers of files.
Such services can include web caches, large mail systems, and news systems.
Turning on this option will generally not reduce performance even with the
@@ -270,7 +270,7 @@
improve bandwidth utilization by increasing the default at the cost of
eating up more kernel memory for each connection. We do not recommend
increasing the defaults if you are serving hundreds or thousands of
-simultanious connections because it is possible to quickly run the system
+simultaneous connections because it is possible to quickly run the system
out of memory due to stalled connections building up. But if you need
high bandwidth over a fewer number of connections, especially if you have
gigabit ethernet, increasing these defaults can make a huge difference.
@@ -280,7 +280,7 @@
without eating too much kernel memory. Note that the route table, see
.Xr route 8 ,
can be used to introduce route-specific send and receive buffer size
-defaults. As an additional mangagement tool you can use pipes in your
+defaults. As an additional management tool you can use pipes in your
firewall rules, see
.Xr ipfw 8 ,
to limit the bandwidth going to or from particular IP blocks or ports.
@@ -296,9 +296,9 @@
We recommend that you turn on (set to 1) and leave on the
.Em net.inet.tcp.always_keepalive
control. The default is usually off. This introduces a small amount of
-additional network bandwidth but guarentees that dead tcp connections
+additional network bandwidth but guarantees that dead tcp connections
will eventually be recognized and cleared. Dead tcp connections are a
-particular problem on systems accesed by users operating over dialups,
+particular problem on systems accessed by users operating over dialups,
because users often disconnect their modems without properly closing active
connections.
.Pp
@@ -339,7 +339,7 @@
willing to allocate. Each cluster represents approximately 2K of memory,
so a value of 1024 represents 2M of kernel memory reserved for network
buffers. You can do a simple calculation to figure out how many you need.
-If you have a web server which maxes out at 1000 simultanious connections,
+If you have a web server which maxes out at 1000 simultaneous connections,
and each connection eats a 16K receive and 16K send buffer, you need
approximate 32MB worth of network buffers to deal with it. A good rule of
thumb is to multiply by 2, so 32MBx2 = 64MB/2K = 32768. So for this case
@@ -413,7 +413,7 @@
.Sh CPU, MEMORY, DISK, NETWORK
The type of tuning you do depends heavily on where your system begins to
bottleneck as load increases. If your system runs out of cpu (idle times
-are pepetually 0%) then you need to consider upgrading the cpu or moving to
+are perpetually 0%) then you need to consider upgrading the cpu or moving to
an SMP motherboard (multiple cpu's), or perhaps you need to revisit the
programs that are causing the load and try to optimize them. If your system
is paging to swap a lot you need to consider adding more memory. If your
@@ -436,7 +436,7 @@
.Xr firewall 7
we describe a firewall protecting internal hosts with a topology where
the externally visible hosts are not routed through it. Use 100BaseT rather
-then 10BaseT, or use 1000BaseT rather then 100BaseT, depending on your needs.
+than 10BaseT, or use 1000BaseT rather than 100BaseT, depending on your needs.
Most bottlenecks occur at the WAN link (e.g. modem, T1, DSL, whatever).
If expanding the link is not an option it may be possible to use ipfw's
.Sy DUMMYNET
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106050405.f5545pb18885>