svn commit: r52156 - head/en_US.ISO8859-1/books/faq

Benedict Reuschling <[email protected]>
Newsgroups gmane.os.freebsd.devel.cvs.doc
Message-ID <[email protected]>
Author: bcr
Date: Sun Aug 19 11:51:30 2018
New Revision: 52156
URL: https://svnweb.freebsd.org/changeset/doc/52156

Log:
  Wrap long lines, put some content on the same line as the opening tags, and
  properly intent nested tags to make textproc/igor happy.

Modified:
  head/en_US.ISO8859-1/books/faq/book.xml

Modified: head/en_US.ISO8859-1/books/faq/book.xml
==============================================================================
--- head/en_US.ISO8859-1/books/faq/book.xml	Sun Aug 19 07:19:18 2018	(r52155)
+++ head/en_US.ISO8859-1/books/faq/book.xml	Sun Aug 19 11:51:30 2018	(r52156)
@@ -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>
@@ -546,7 +548,7 @@
 	<answer>
 	  <para>Every significant release of &os; is available via
 	    anonymous FTP from the <link
-	      xlink:href="ftp://ftp.FreeBSD.org/pub/FreeBSD/"> &os;
+	      xlink:href="ftp://ftp.FreeBSD.org/pub/FreeBSD/">&os;
 	      FTP site</link>:</para>
 
 	  <itemizedlist>
@@ -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>
 
@@ -3407,156 +3408,154 @@ kern.sched.name: ULE</screen>
   </chapter>
 
   <chapter xml:id="all-about-zfs">
-      <title>ZFS</title>
+    <title>ZFS</title>
 
-      <qandaset>
-	<qandaentry>
-	  <question xml:id="how-much-ram-for-zfs">
-	    <para>What is the minimum amount of RAM one should have to
-	      run ZFS?</para>
-	  </question>
+    <qandaset>
+      <qandaentry>
+	<question xml:id="how-much-ram-for-zfs">
+	  <para>What is the minimum amount of RAM one should have to
+	    run ZFS?</para>
+	</question>
 
-	  <answer>
-	    <para>A minimum of 4GB of RAM is required for comfortable
-	      usage, but individual workloads can vary widely.</para>
-	  </answer>
-	</qandaentry>
+	<answer>
+	  <para>A minimum of 4GB of RAM is required for comfortable
+	    usage, but individual workloads can vary widely.</para>
+	</answer>
+      </qandaentry>
 
-	<qandaentry>
-	  <question xml:id="what-is-zil">
-	    <para>What is the ZIL and when does it get used?</para>
-	  </question>
+      <qandaentry>
+	<question xml:id="what-is-zil">
+	  <para>What is the ZIL and when does it get used?</para>
+	</question>
 
-	  <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>
-	  </answer>
-	</qandaentry>
+	<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>
+	</answer>
+      </qandaentry>
 
-	<qandaentry>
-	  <question xml:id="need-ssd-for-zil">
-	    <para>Do I need a SSD for ZIL?</para>
-	  </question>
+      <qandaentry>
+	<question xml:id="need-ssd-for-zil">
+	  <para>Do I need a SSD for ZIL?</para>
+	</question>
 
-	  <answer>
-	    <para>By default, ZFS stores the ZIL in the pool with all
-	      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>
-	  </answer>
-	</qandaentry>
+	<answer>
+	  <para>By default, ZFS stores the ZIL in the pool with all
+	    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>
+	</answer>
+      </qandaentry>
 
-	<qandaentry>
-	  <question xml:id="what-is-l2arc">
-	    <para>What is the L2ARC?</para>
-	  </question>
+      <qandaentry>
+	<question xml:id="what-is-l2arc">
+	  <para>What is the L2ARC?</para>
+	</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>
+	<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>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>
-	  </answer>
-	</qandaentry>
+	  <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>
+	</answer>
+      </qandaentry>
 
-	<qandaentry>
-	  <question xml:id="should-enable-dedup">
-	    <para>Is enabling deduplication advisable?</para>
-	  </question>
+      <qandaentry>
+	<question xml:id="should-enable-dedup">
+	  <para>Is enabling deduplication advisable?</para>
+	</question>
 
-	  <answer>
-	    <para>Generally speaking, no.</para>
+	<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>
-	  </answer>
-	</qandaentry>
+	  <para>Deduplication can also lead to some unexpected
+	    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>
-	  </question>
+      <qandaentry>
+	<question xml:id="zpool-fully-full">
+	  <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>
+	<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>
 
-	    <screen>&prompt.user; <userinput>truncate -s 0 unimportant-file</userinput></screen>
+	  <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>
-	    </note>
-	  </answer>
-	</qandaentry>
+	  <note>
+	    <para>On systems with additional ZFS dataset tuning, such
+	      as deduplication, the space may not be immediately
+	      available</para>
+	  </note>
+	</answer>
+      </qandaentry>
 
-	<qandaentry>
-	  <question xml:id="zfs-ssd-trim">
-	    <para>Does ZFS support TRIM for Solid State Drives?</para>
-	  </question>
+      <qandaentry>
+	<question xml:id="zfs-ssd-trim">
+	  <para>Does ZFS support TRIM for Solid State Drives?</para>
+	</question>
 
-	  <answer>
-	    <para>ZFS TRIM support was added to &os;&nbsp;10-CURRENT
-	      with revision r<revnumber>240868</revnumber>.  ZFS TRIM
-	      support was added to all &os;-STABLE branches in
-	      r<revnumber>252162</revnumber> and
-	      r<revnumber>251419</revnumber>, respectively.</para>
+	<answer>
+	  <para>ZFS TRIM support was added to &os;&nbsp;10-CURRENT
+	    with revision r<revnumber>240868</revnumber>.  ZFS TRIM
+	    support was added to all &os;-STABLE branches in
+	    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
-	      <filename>/etc/sysctl.conf</filename>:</para>
+	  <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>
+	  <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>
-	    </note>
-	  </answer>
-	</qandaentry>
-      </qandaset>
+	  <note>
+	    <para>ZFS TRIM may not work with all configurations, such
+	      as a ZFS filesystem on a GELI-backed device.</para>
+	  </note>
+	</answer>
+      </qandaentry>
+    </qandaset>
   </chapter>
 
   <chapter xml:id="admin">
@@ -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
@@ -3709,7 +3708,7 @@ kern.sched.name: ULE</screen>
 	  <para>See the <link
 	      xlink:href="&url.books.handbook;/printing.html">Handbook
 	      entry on printing</link> for troubleshooting
-	      tips.</para>
+	    tips.</para>
 	</answer>
       </qandaentry>
 
@@ -4112,10 +4111,10 @@ options    SYSVMSG          # enable for messaging</pr
 
 	<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>
 
@@ -4416,7 +4415,7 @@ options    SYSVMSG          # enable for messaging</pr
 	    <filename>/etc/X11/xorg.conf</filename>, as seen in this
 	    example:</para>
 
-          <programlisting>Section "InputDevice"
+	  <programlisting>Section "InputDevice"
    Identifier      "Mouse1"
    Driver          "mouse"
    Option          "Protocol" "auto"
@@ -5262,16 +5261,13 @@ Key F15        A        A        Menu Workplace Nop</p
 	</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>
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/svn-doc-all
To unsubscribe, send any mail to "[email protected]"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.