svn commit: r44501 - head/en_US.ISO8859-1/books/handbook/disks

Dru Lavigne dru at FreeBSD.org
Wed Apr 9 14:04:20 UTC 2014


Author: dru
Date: Wed Apr  9 14:04:20 2014
New Revision: 44501
URL: http://svnweb.freebsd.org/changeset/doc/44501

Log:
  White space fix only. Translators can ignore.
  
  Sponsored by:	iXsystems

Modified:
  head/en_US.ISO8859-1/books/handbook/disks/chapter.xml

Modified: head/en_US.ISO8859-1/books/handbook/disks/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/disks/chapter.xml	Wed Apr  9 13:44:05 2014	(r44500)
+++ head/en_US.ISO8859-1/books/handbook/disks/chapter.xml	Wed Apr  9 14:04:20 2014	(r44501)
@@ -3675,21 +3675,20 @@ Device          1K-blocks     Used    Av
 
 	<para>The goal of this example is to build a robust storage
 	  system which is resistant to the failure of any given node.
-	  If the primary node
-	  fails, the
-	  secondary node is there to take over
-	  seamlessly, check and mount the file system, and continue to
-	  work without missing a single bit of data.</para>
-
-	<para>To accomplish this task, the Common
-	  Address Redundancy Protocol
-	  (<acronym>CARP</acronym>) is used to provide for automatic failover at
-	  the <acronym>IP</acronym> layer.  <acronym>CARP</acronym> allows multiple hosts on the
-	  same network segment to share an <acronym>IP</acronym> address.  Set up
-	  <acronym>CARP</acronym> on both nodes of the cluster
-	  according to the documentation available in
-	  <xref linkend="carp"/>.  In this example, each node will
-	  have its own management <acronym>IP</acronym> address and a
+	  If the primary node fails, the secondary node is there to
+	  take over seamlessly, check and mount the file system, and
+	  continue to work without missing a single bit of
+	  data.</para>
+
+	<para>To accomplish this task, the Common Address Redundancy
+	  Protocol (<acronym>CARP</acronym>) is used to provide for
+	  automatic failover at the <acronym>IP</acronym> layer.
+	  <acronym>CARP</acronym> allows multiple hosts on the same
+	  network segment to share an <acronym>IP</acronym> address.
+	  Set up <acronym>CARP</acronym> on both nodes of the cluster
+	  according to the documentation available in <xref
+	    linkend="carp"/>.  In this example, each node will have
+	  its own management <acronym>IP</acronym> address and a
 	  shared <acronym>IP</acronym> address of
 	  <replaceable>172.16.0.254</replaceable>.  The primary
 	  <acronym>HAST</acronym> node of the cluster must be the
@@ -3699,10 +3698,11 @@ Device          1K-blocks     Used    Av
 	  section is now ready to be exported to the other hosts on
 	  the network.  This can be accomplished by exporting it
 	  through <acronym>NFS</acronym> or
-	  <application>Samba</application>, using the shared <acronym>IP</acronym>
-	  address <replaceable>172.16.0.254</replaceable>.  The only
-	  problem which remains unresolved is an automatic failover
-	  should the primary node fail.</para>
+	  <application>Samba</application>, using the shared
+	  <acronym>IP</acronym> address
+	  <replaceable>172.16.0.254</replaceable>.  The only problem
+	  which remains unresolved is an automatic failover should the
+	  primary node fail.</para>
 
 	<para>In the event of <acronym>CARP</acronym> interfaces going
 	  up or down, the &os; operating system generates a
@@ -3714,9 +3714,8 @@ Device          1K-blocks     Used    Av
 	  which will automatically handle the HAST failover.</para>
 
 	<para>To catch state changes on the
-	  <acronym>CARP</acronym> interfaces, add this
-	  configuration to
-	  <filename>/etc/devd.conf</filename> on each node:</para>
+	  <acronym>CARP</acronym> interfaces, add this configuration
+	  to <filename>/etc/devd.conf</filename> on each node:</para>
 
 	<programlisting>notify 30 {
 	match "system" "IFNET";
@@ -3743,16 +3742,16 @@ notify 30 {
 
 	<screen>&prompt.root; <userinput>service devd restart</userinput></screen>
 
-	<para>When the specified interface state
-	  changes by going up or down , the system generates a
-	  notification, allowing the &man.devd.8; subsystem to run the
-	  specified automatic failover script,
+	<para>When the specified interface state changes by going up
+	  or down , the system generates a notification, allowing the
+	  &man.devd.8; subsystem to run the specified automatic
+	  failover script,
 	  <filename>/usr/local/sbin/carp-hast-switch</filename>.
-	  For further
-	  clarification about this configuration,
-	  refer to &man.devd.conf.5;.</para>
+	  For further clarification about this configuration, refer to
+	  &man.devd.conf.5;.</para>
 
-	<para>Here is an example of an automated failover script:</para>
+	<para>Here is an example of an automated failover
+	  script:</para>
 
 	<programlisting>#!/bin/sh
 
@@ -3857,8 +3856,7 @@ esac</programlisting>
 	  </listitem>
 	</itemizedlist>
 
-	<para>When a node becomes
-	  secondary:</para>
+	<para>When a node becomes secondary:</para>
 
 	<itemizedlist>
 	  <listitem>
@@ -3872,16 +3870,18 @@ esac</programlisting>
 	</itemizedlist>
 
 	<caution>
-	  <para>This is just an example script which
-	    serves as a proof of concept.  It does not handle all the
-	    possible scenarios and can be extended or altered in any
-	    way, for example, to start or stop required services.</para>
+	  <para>This is just an example script which serves as a proof
+	    of concept.  It does not handle all the possible scenarios
+	    and can be extended or altered in any way, for example, to
+	    start or stop required services.</para>
 	</caution>
 
 	<tip>
-	  <para>For this example, a standard <acronym>UFS</acronym> file system was used.
-	    To reduce the time needed for recovery, a journal-enabled
-	    <acronym>UFS</acronym> or <acronym>ZFS</acronym> file system can be used instead.</para>
+	  <para>For this example, a standard <acronym>UFS</acronym>
+	    file system was used.  To reduce the time needed for
+	    recovery, a journal-enabled <acronym>UFS</acronym> or
+	    <acronym>ZFS</acronym> file system can be used
+	    instead.</para>
 	</tip>
 
 	<para>More detailed information with additional examples can
@@ -3902,21 +3902,21 @@ esac</programlisting>
 
       <para>When troubleshooting <acronym>HAST</acronym>, the
 	debugging level of &man.hastd.8; should be increased by
-	starting <command>hastd</command> with <literal>-d</literal>.  This
-	argument may be specified multiple times to further increase
-	the debugging level.  Consider also using
-	<literal>-F</literal>, which starts <command>hastd</command> in the
-	foreground.</para>
+	starting <command>hastd</command> with <literal>-d</literal>.
+	This argument may be specified multiple times to further
+	increase the debugging level.  Consider also using
+	<literal>-F</literal>, which starts <command>hastd</command>
+	in the foreground.</para>
 
       <sect3 xml:id="disks-hast-sb">
 	<title>Recovering from the Split-brain Condition</title>
 
-	<para><firstterm>Split-brain</firstterm> occurs when the nodes of the
-	  cluster are unable to communicate with each other, and both
-	  are configured as primary.  This is a dangerous condition
-	  because it allows both nodes to make incompatible changes to
-	  the data.  This problem must be corrected manually by the
-	  system administrator.</para>
+	<para><firstterm>Split-brain</firstterm> occurs when the nodes
+	  of the cluster are unable to communicate with each other,
+	  and both are configured as primary.  This is a dangerous
+	  condition because it allows both nodes to make incompatible
+	  changes to the data.  This problem must be corrected
+	  manually by the system administrator.</para>
 
 	<para>The administrator must decide which node has more
 	  important changes or merge them manually.  Then, let


More information about the svn-doc-all mailing list