LUDOC 299 protocol: Spell-check document

[doc/protocol.git] / struct_obd_export.txt

diff --git a/struct_obd_export.txt b/struct_obd_export.txt
index c7e1636..3f30728 100644 (file)
--- a/struct_obd_export.txt
+++ b/struct_obd_export.txt
@@ -104,7 +104,7 @@ target will increment the refcount. A reference by an LDLM lock that
 gets taken will increment the refcount. Callback invocations and
 replay also lead to incrementing the 'ref_count'. The next four fields
 - 'exp_rpc_count', exp_cb_count', and 'exp_replay_count', and
-'exp_locks_count' - all subcategorize the 'exp_refcount'. The
+'exp_locks_count' - all sub-categorize the 'exp_refcount'. The
 reference counter keeps the export alive while there are any users of
 that export. The reference counter is also used for debug
 purposes. Similarly, the 'exp_locks_list' and 'exp_locks_list_guard'
@@ -116,11 +116,10 @@ are further debug info that list the actual locks accounted for in
 include::struct_obd_uuid.txt[]
 
 The 'exp_client_uuid' holds the UUID of the client connected to this
-export.  This UUID is randomly generated by the client and the same
-UUID is used by the client for connecting to all servers, so that the
-servers may identify the client amongst themselves if necessary. The
-client's UID appears in the *_CONNECT message (See
-<<ost-connect-rpc>>, <<mds-connect-rpc>>, and <<mgs-connect-rpc>>).
+export.  This UUID is randomly generated by the client, and the same
+UUID is used by the client for connecting to all servers. The client's
+UID appears in the *_CONNECT message (See <<ost-connect-rpc>>,
+<<mds-connect-rpc>>, and <<mgs-connect-rpc>>).
 
 //////////////////////////////////////////////////////////////////////
 ////vvvv
@@ -174,7 +173,7 @@ deadlock detection.
 
 For those requests that initiate file system modifying transactions
 the request and its attendant locks need to be preserved until either
-a) the client acknowleges recieving the reply, or b) the transaction
+a) the client acknowledges receiving the reply, or b) the transaction
 has been committed locally. This ensures a request can be replayed in
 the event of a failure. The LDLM lock is being kept until one of these
 event occurs to prevent any other modifications of the same object.