summaryrefslogtreecommitdiff
path: root/ctdb
diff options
context:
space:
mode:
authorBjörn Baumbach <bb@sernet.de>2017-12-18 10:48:54 +0100
committerAndrew Bartlett <abartlet@samba.org>2017-12-19 07:19:21 +0100
commit38ed5920764d1490bfa4201f62d61cbcd8d8166e (patch)
tree5e8f853f93f6e1770cd57dd4c4c303dccc7b089e /ctdb
parent3efc879d98ba136d4d70e0e2d77fac9614186ab3 (diff)
downloadsamba-38ed5920764d1490bfa4201f62d61cbcd8d8166e.tar.gz
doc/ctdb: fix two typos
Signed-off-by: Björn Baumbach <bb@sernet.de> Reviewed-by: Volker Lendecke <vl@samba.org> Reviewed-by: Martin Schwenke <martin@meltin.net> Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Diffstat (limited to 'ctdb')
-rw-r--r--ctdb/doc/ctdb.7.xml4
1 files changed, 2 insertions, 2 deletions
diff --git a/ctdb/doc/ctdb.7.xml b/ctdb/doc/ctdb.7.xml
index db0a627984c..5f5332e7640 100644
--- a/ctdb/doc/ctdb.7.xml
+++ b/ctdb/doc/ctdb.7.xml
@@ -501,7 +501,7 @@ Node 3:/usr/local/etc/ctdb/public_addresses
the internal network to one of the nodes that LVS is using.
When responding to the client, that node will send the data back
directly to the client, bypassing the LVS master node. The
- command <command>ctdb lvsmaster</command> will show which node
+ command <command>ctdb lvs master</command> will show which node
is the current LVS master.
</para>
@@ -539,7 +539,7 @@ Node 3:/usr/local/etc/ctdb/public_addresses
multiplex. This means that you should not use LVS if your I/O
pattern is write-intensive since you will be limited in the
available network bandwidth that node can handle. LVS does work
- wery well for read-intensive workloads where only smallish READ
+ very well for read-intensive workloads where only smallish READ
requests are going through the LVSMASTER bottleneck and the
majority of the traffic volume (the data in the read replies)
goes straight from the processing node back to the clients. For