LUDOC 299 protocol: Spell-check document

[doc/protocol.git] / getattr.txt

diff --git a/getattr.txt b/getattr.txt
index 44edcbf..65c40b9 100644 (file)
--- a/getattr.txt
+++ b/getattr.txt
@@ -159,7 +159,7 @@ with this set of valid fields (0x8080022f8f):
 | OBD_MD_FLACL       | ACL
 |====
 
-As a bonus the MDT returnes layout information about the file, so that
+As a bonus the MDT returns layout information about the file, so that
 Client1 can get attribute information from the OST(s) responsible
 for the file's objects (if any).
 
@@ -185,7 +185,7 @@ The ldlm-enqueue-request.png diagram resembles this text art:
 
 See <<ldlm-enqueue-rpc>>.
 
-*4 - The OST invokes a glimps lock callback on Client2.*
+*4 - The OST invokes a glimpse lock callback on Client2.*
 
 Client2 previously had a lock on the desired resource, and the glimpse
 induces Client2 to flush its buffers, if needed, and update the OST
@@ -209,7 +209,7 @@ See <<ldlm-gl-callback-rpc>>.
 *5 - Client2 replies with LVB data for the OST.*
 
 The OST is waiting to hear back from Client2 to update size and time
-attributes, if needed, due to Client2 chache being flushed to the
+attributes, if needed, due to Client2 cache being flushed to the
 OST. The glimpse allows the information to return to the OST, and
 thereby get passed to Client1, without taking the lock from Client2.
 
@@ -225,7 +225,7 @@ The ldlm-gl-callback-reply.png diagram resembles this text art:
       -------------------------
 //////////////////////////////////////////////////////////////////////
 
-The 'ost_lvb' data from Client2 has atribute data to update the OST.
+The 'ost_lvb' data from Client2 has attribute data to update the OST.
 
 *6 - The OST replies with the updated attribute information.*