ctdb:doc: Fix code spelling

Best reviewed with: `git show --word-diff`.

Signed-off-by: Andreas Schneider <asn@samba.org>
Reviewed-by: Andrew Bartlett <abartlet@samba.org>

diff --git a/ctdb/doc/ctdb-tunables.7.xml b/ctdb/doc/ctdb-tunables.7.xml
index 700709eb86fdcb47ed0ca2311ab9ef29111f62b4..df7b0ea9dc9ae7c7cc64dc873be052f1cde36f6a 100644 (file)
--- a/ctdb/doc/ctdb-tunables.7.xml
+++ b/ctdb/doc/ctdb-tunables.7.xml
@@ -131,7 +131,7 @@ MonitorInterval=20
       <title>DatabaseMaxDead</title>
       <para>Default: 5</para>
       <para>
-       Maximum number of dead records per hash chain for the tdb databses
+       Maximum number of dead records per hash chain for the tdb databases
        managed by ctdb.
       </para>
     </refsect2>

diff --git a/ctdb/doc/ctdb.1.xml b/ctdb/doc/ctdb.1.xml
index 6f9a1764ee4d3a3d1ae9b89373a304ecdc00f456..65c254762ebaa45f9ddaa46d08dca60b63c653de 100644 (file)
--- a/ctdb/doc/ctdb.1.xml
+++ b/ctdb/doc/ctdb.1.xml
@@ -252,8 +252,8 @@
       <refsect3>
        <title>Generation</title>
        <para>
-         The generation id is a number that indicates the current generation 
-         of a cluster instance. Each time a cluster goes through a 
+         The generation id is a number that indicates the current generation
+         of a cluster instance. Each time a cluster goes through a
          reconfiguration or a recovery its generation id will be changed.
        </para>
        <para>
@@ -299,11 +299,11 @@
          RECOVERY - The cluster databases have all been frozen, pausing all services while the cluster awaits a recovery process to complete. A recovery process should finish within seconds. If a cluster is stuck in the RECOVERY state this would indicate a cluster malfunction which needs to be investigated.
        </para>
        <para>
-         Once the leader detects an inconsistency, for example a node 
-         becomes disconnected/connected, the recovery daemon will trigger a 
+         Once the leader detects an inconsistency, for example a node
+         becomes disconnected/connected, the recovery daemon will trigger a
          cluster recovery process, where all databases are remerged across the
          cluster. When this process starts, the leader will first
-         "freeze" all databases to prevent applications such as samba from 
+         "freeze" all databases to prevent applications such as samba from
          accessing the databases and it will also mark the recovery mode as
          RECOVERY.
        </para>
@@ -321,7 +321,7 @@
          This is the cluster node that is currently designated as the
          leader. This node is responsible of monitoring the
          consistency of the cluster and to perform the actual
-         recovery process when reqired.
+         recovery process when required.
        </para>
        <para>
          Only one node at a time can be the designated leader. Which
@@ -1127,7 +1127,7 @@ DB Statistics: locking.tdb
       <para>
        This command is used to administratively STOP a node in the cluster.
        A STOPPED node is connected to the cluster but will not host any
-       public ip addresse, nor does it participate in the VNNMAP.
+       public ip addresses, nor does it participate in the VNNMAP.
        The difference between a DISABLED node and a STOPPED node is that
        a STOPPED node does not host any parts of the database which means
        that a recovery is required to stop/continue nodes.
@@ -1183,7 +1183,7 @@ DB Statistics: locking.tdb
        specific node.
       </para>
       <para>
-       In order to manually override the "automatic" distribution of public 
+       In order to manually override the "automatic" distribution of public
        ip addresses that ctdb normally provides, this command only works
        when you have changed the tunables for the daemon to:
       </para>

diff --git a/ctdb/doc/readonlyrecords.txt b/ctdb/doc/readonlyrecords.txt
index cc6d7ee269d4360116d960e7d577153be7b16008..e7be1c313b2dcf472f04905131bc251f3f7636ab 100644 (file)
--- a/ctdb/doc/readonlyrecords.txt
+++ b/ctdb/doc/readonlyrecords.txt
@@ -121,7 +121,7 @@ very many readonly requests.
 
 
 The ctdb_db structure is expanded so that it contains one extra TDB database for each
-normal, non-persistent datbase.
+normal, non-persistent database.
 This new database is used for tracking delegations for the records.
 A record in the normal database that has "HAVE_DELEGATION" set will always have a
 corresponding record at the same key. This record contains the set of all nodes that
@@ -334,7 +334,7 @@ Non-readonly enabled daemons fetching records from Readonly enabled daemons:
 Non-readonly enabled daemons do not know, and never set the WANT_READONLY flag so these daemons will always request a full migration for a full fetch-lock for all records. Thus a request from a non-readonly enabled daemon will always cause any existing delegations to be immediately revoked. Access will work but performance may be harmed since there will be a lot of revoking of delegations.
 
 Readonly enabled daemons fetching records with WANT_READONLY from non-readonly enabled daemons:
-Non-readonly enabled daemons ingore the WANT_READONLY flag and never return delegations. They always return a full record migration.
+Non-readonly enabled daemons ignore the WANT_READONLY flag and never return delegations. They always return a full record migration.
 Full record migration is allowed by the protocol, even if the originator only requests the 'hint' WANT_READONLY,
 so this access also interoperates between daemons with different capabilities.