Wrap long lines, put some content on the same line as the opening tags, and

properly intent nested tags to make textproc/igor happy.
This commit is contained in:
Benedict Reuschling 2018-08-19 11:51:30 +00:00
parent 3b24ec7126
commit 18da88da15
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=52156

View file

@ -15,7 +15,9 @@
<!ENTITY rel2.releng "<symbol xmlns='http://docbook.org/ns/docbook'>stable/10/</symbol>">
<!ENTITY rel2.relengdate "August 2015">
]>
<book xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<book xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:lang="en">
<info>
<title>Frequently Asked Questions for &os;
&rel2.relx; and &rel.relx;</title>
@ -878,7 +880,7 @@
<para>Where the format is
<literal>html-split</literal>, the files are
bundled up using &man.tar.1;. The resulting
<filename>.tar</filename> file is then compressed
<filename>.tar</filename> is then compressed
using the compression schemes detailed in the next
point.</para>
</listitem>
@ -2411,19 +2413,19 @@ kern.timecounter.hardware: TSC -&gt; i8254</screen>
</question>
<answer>
<para>If the installed &os; version lags
significantly behind <emphasis>-CURRENT</emphasis> or
<emphasis>-STABLE</emphasis>, update the
Ports Collection using the instructions in <link
<para>If the installed &os; version lags significantly
behind <emphasis>-CURRENT</emphasis> or
<emphasis>-STABLE</emphasis>, update the Ports Collection
using the instructions in <link
xlink:href="&url.books.handbook;/ports-using.html">Using
the Ports Collection</link>. If the system is
up-to-date, someone might have committed a change to the
port which works for <emphasis>-CURRENT</emphasis> but
which broke the port for <emphasis>-STABLE</emphasis>.
<link xlink:href="https://bugs.FreeBSD.org/submit/">Submit</link>
<link
xlink:href="https://bugs.FreeBSD.org/submit/">Submit</link>
a bug report, since the Ports Collection is supposed to
work
for both the <emphasis>-CURRENT</emphasis> and
work for both the <emphasis>-CURRENT</emphasis> and
<emphasis>-STABLE</emphasis> branches.</para>
</answer>
</qandaentry>
@ -2696,9 +2698,8 @@ kern.timecounter.hardware: TSC -&gt; i8254</screen>
</listitem>
<listitem>
<para>The <command>make
buildkernel</command> command did not complete
successfully. The <command>make
<para>The <command>make buildkernel</command> did not
complete successfully. The <command>make
buildkernel</command> target relies on files
generated by the <command>make buildworld</command>
target to complete its job correctly.</para>
@ -3356,8 +3357,8 @@ kern.sched.name: ULE</screen>
<answer>
<para>This section <link
xlink:href="&url.books.handbook;/adding-swap-space.html">of the Handbook</link>
describes how to do this.</para>
xlink:href="&url.books.handbook;/adding-swap-space.html">of
the Handbook</link> describes how to do this.</para>
</answer>
</qandaentry>
@ -3430,17 +3431,17 @@ kern.sched.name: ULE</screen>
<answer>
<para>The <acronym>ZIL</acronym> (<acronym>ZFS</acronym>
intent log) is a write log used to implement posix write
commitment semantics across crashes. Normally writes
are bundled up into transaction groups and written to
disk when filled (<quote>Transaction Group
Commit</quote>). However syscalls like &man.fsync.2;
require a commitment that the data is written to stable
storage before returning. The ZIL is needed for writes
that have been acknowledged as written but which are not
yet on disk as part of a transaction. The transaction
groups are timestamped. In the event of a crash the
last valid timestamp is found and missing data is merged
in from the ZIL.</para>
commitment semantics across crashes. Normally writes are
bundled up into transaction groups and written to disk
when filled (<quote>Transaction Group Commit</quote>).
However syscalls like &man.fsync.2; require a commitment
that the data is written to stable storage before
returning. The ZIL is needed for writes that have been
acknowledged as written but which are not yet on disk as
part of a transaction. The transaction groups are
timestamped. In the event of a crash the last valid
timestamp is found and missing data is merged in from the
ZIL.</para>
</answer>
</qandaentry>
@ -3454,8 +3455,8 @@ kern.sched.name: ULE</screen>
the data. If an application has a heavy write load,
storing the ZIL in a separate device that has very fast
synchronous, sequential write performance can improve
overall system. For other workloads, a SSD is unlikely
to make much of an improvement.</para>
overall system. For other workloads, a SSD is unlikely to
make much of an improvement.</para>
</answer>
</qandaentry>
@ -3465,18 +3466,18 @@ kern.sched.name: ULE</screen>
</question>
<answer>
<para>The <acronym>L2ARC</acronym> is a read cache stored
on a fast device such as an <acronym>SSD</acronym>.
This cache is not persistent across reboots. Note that
RAM is used as the first layer of cache and the L2ARC is
only needed if there is insufficient RAM.</para>
<para>The <acronym>L2ARC</acronym> is a read cache stored on
a fast device such as an <acronym>SSD</acronym>. This
cache is not persistent across reboots. Note that RAM is
used as the first layer of cache and the L2ARC is only
needed if there is insufficient RAM.</para>
<para>L2ARC needs space in the ARC to index it. So,
perversely, a working set that fits perfectly in the
ARC will not fit perfectly any more if a L2ARC is used
because part of the ARC is holding the L2ARC index,
pushing part of the working set into the L2ARC which is
slower than RAM.</para>
perversely, a working set that fits perfectly in the ARC
will not fit perfectly any more if a L2ARC is used because
part of the ARC is holding the L2ARC index, pushing part
of the working set into the L2ARC which is slower than
RAM.</para>
</answer>
</qandaentry>
@ -3488,45 +3489,44 @@ kern.sched.name: ULE</screen>
<answer>
<para>Generally speaking, no.</para>
<para>Deduplication takes up a significant amount of RAM
and may slow down read and write disk access times.
Unless one is storing data that is very heavily
duplicated, such as virtual machine images or user
backups, it is possible that deduplication will do more
harm than good. Another consideration is the inability
to revert deduplication status. If data is written when
deduplication is enabled, disabling dedup will not cause
those blocks which were deduplicated to be replicated
until they are next modified.</para>
<para>Deduplication takes up a significant amount of RAM and
may slow down read and write disk access times. Unless
one is storing data that is very heavily duplicated, such
as virtual machine images or user backups, it is possible
that deduplication will do more harm than good. Another
consideration is the inability to revert deduplication
status. If data is written when deduplication is enabled,
disabling dedup will not cause those blocks which were
deduplicated to be replicated until they are next
modified.</para>
<para>Deduplication can also lead to some unexpected
situations. In particular, deleting files may become
much slower.</para>
situations. In particular, deleting files may become much
slower.</para>
</answer>
</qandaentry>
<qandaentry>
<question xml:id="zpool-fully-full">
<para>I cannot delete or create files on my ZFS pool.
How can I fix this?</para>
<para>I cannot delete or create files on my ZFS pool. How
can I fix this?</para>
</question>
<answer>
<para>This could happen because the pool is 100% full.
ZFS requires space on the disk to write transaction
metadata. To restore the pool to a usable state,
truncate the file to delete:</para>
<para>This could happen because the pool is 100% full. ZFS
requires space on the disk to write transaction metadata.
To restore the pool to a usable state, truncate the file
to delete:</para>
<screen>&prompt.user; <userinput>truncate -s 0 unimportant-file</userinput></screen>
<para>File truncation works because a new transaction is
not started, new spare blocks are created
instead.</para>
<para>File truncation works because a new transaction is not
started, new spare blocks are created instead.</para>
<note>
<para>On systems with additional ZFS dataset tuning,
such as deduplication, the space may not be
immediately available</para>
<para>On systems with additional ZFS dataset tuning, such
as deduplication, the space may not be immediately
available</para>
</note>
</answer>
</qandaentry>
@ -3543,16 +3543,15 @@ kern.sched.name: ULE</screen>
r<revnumber>252162</revnumber> and
r<revnumber>251419</revnumber>, respectively.</para>
<para>ZFS TRIM is enabled by default, and can be turned
off by adding this line to
<para>ZFS TRIM is enabled by default, and can be turned off
by adding this line to
<filename>/etc/sysctl.conf</filename>:</para>
<programlisting>vfs.zfs.trim_disable=1</programlisting>
<note>
<para>ZFS TRIM may not work with all configurations,
such as a ZFS filesystem on a GELI-backed
device.</para>
<para>ZFS TRIM may not work with all configurations, such
as a ZFS filesystem on a GELI-backed device.</para>
</note>
</answer>
</qandaentry>
@ -3675,15 +3674,15 @@ kern.sched.name: ULE</screen>
<para>Restart the system using <userinput>boot
-s</userinput> at the loader prompt to enter single-user
mode. When prompted for a shell pathname, press
<keycap>Enter</keycap> and run <command>mount
-urw /</command> to re-mount the root file system in
<keycap>Enter</keycap> and run <command>mount -urw
/</command> to re-mount the root file system in
read/write mode. You may also need to run <command>mount
-a -t ufs</command> to mount the file system where your
favorite editor is defined. If that editor is on
a network file system, either configure
the network manually before mounting the network file
systems, or use an editor which resides on a local file
system, such as &man.ed.1;.</para>
favorite editor is defined. If that editor is on a
network file system, either configure the network manually
before mounting the network file systems, or use an editor
which resides on a local file system, such as
&man.ed.1;.</para>
<para>In order to use a full screen editor such as
&man.vi.1; or &man.emacs.1;, run
@ -4112,10 +4111,10 @@ options SYSVMSG # enable for messaging</programlisting>
<answer>
<para>The system is running at securelevel greater than 0.
Lower the securelevel and try again. For
more information, see <link linkend="securelevel">the <acronym>FAQ</acronym>
entry on securelevel</link> and the &man.init.8; manual
page.</para>
Lower the securelevel and try again. For more
information, see <link linkend="securelevel">the
<acronym>FAQ</acronym> entry on securelevel</link> and
the &man.init.8; manual page.</para>
</answer>
</qandaentry>
@ -5262,16 +5261,13 @@ Key F15 A A Menu Workplace Nop</programlisting>
</question>
<answer>
<para>
Configure your kernel with these settings:
<screen>
include GENERIC
<para>Configure your kernel with these settings:
<screen>include GENERIC
ident GENERIC-IPV6ONLY
makeoptions MKMODULESENV+="WITHOUT_INET_SUPPORT="
nooptions INET
nodevice gre
</screen>
</para>
nodevice gre</screen></para>
</answer>
</qandaentry>
</qandaset>
@ -6625,8 +6621,8 @@ hint.sio.7.irq="12"</programlisting>
<answer>
<para>See the <link
xlink:href="&url.books.fdp-primer;/translations.html">Translation
<acronym>FAQ</acronym></link> in the &os; Documentation Project
Primer.</para>
<acronym>FAQ</acronym></link> in the &os; Documentation
Project Primer.</para>
</answer>
</qandaentry>
@ -6640,11 +6636,10 @@ hint.sio.7.irq="12"</programlisting>
<answer>
<para>The <systemitem
class="fqdomainname">FreeBSD.org</systemitem> mail
system implements some
<application>Postfix</application> checks on incoming mail
and rejects mail that is either from misconfigured relays
or otherwise appears likely to be spam. Some of the
specific requirements are: </para>
system implements some <application>Postfix</application>
checks on incoming mail and rejects mail that is either
from misconfigured relays or otherwise appears likely to
be spam. Some of the specific requirements are:</para>
<itemizedlist>
<listitem>