[Bug 218538] tuning(7) should either be removed or strictly maintained.
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Mon Apr 10 12:55:37 UTC 2017
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218538
Bug ID: 218538
Summary: tuning(7) should either be removed or strictly
maintained.
Product: Documentation
Version: Latest
Hardware: amd64
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: Documentation
Assignee: freebsd-doc at FreeBSD.org
Reporter: jason at aventia.pw
man tuning comes with the OS, it contains information that may be out of date,
and generally not a good idea to provide advice which can be reversed or
negated with incremental updates. There are plenty of tuning guides not
included with the OS, but when one is included with the OS it must be up to
date.
Example the following excerpt seems to come from the 4.x days, certainly it is
not include or allude to the suggestions to improve performance under ZFS:
<exceprt man tuning FreeBSD 11.0-RELEASE-p8 May 9, 2016>
STRIPING DISKS
In larger systems you can stripe partitions from several drives together
to create a much larger overall partition. Striping can also improve the
performance of a file system by splitting I/O operations across two or
more disks. The gstripe(8), gvinum(8), and ccdconfig(8) utilities may be
used to create simple striped file systems. Generally speaking, striping
smaller partitions such as the root and /var/tmp, or essentially read-
only partitions such as /usr is a complete waste of 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. File systems 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
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 FreeBSD supported controllers.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-doc
mailing list