LUDOC 299 protocol: Spell-check document

[doc/protocol.git] / getxattr.txt

diff --git a/getxattr.txt b/getxattr.txt
index 33d698a..8bff149 100644 (file)
--- a/getxattr.txt
+++ b/getxattr.txt
@@ -2,10 +2,7 @@ Getxattr
 ~~~~~~~~
 
 The 'getxattr' VFS method queries extended attribute information for a
-resource given a path ('getxattr()' system call) or FID ('fgetxattr()'
-system call). If provided a path Lustre will go through a path lookup
-first (not shown [fixme: this should be a cross reference]) in order
-to determine the FID for the resource.
+resource.
 
 Lustre maintains extended attribute information on the MDS, and a
 single RPC (request and reply) retrieves the information from the
@@ -14,7 +11,7 @@ shown in <<getxattr-rpcs>>.
 
 .Getxattr RPCs
 [[getxattr-rpcs]]
-image::getxattr_rpcs.png["getxattr RPCs",height=100]
+image::getxattr_rpcs.png["getxattr RPCs",height=75]
 
 //////////////////////////////////////////////////////////////////////
 The getxattr_rpcs.png diagram resembles this text art:
@@ -26,8 +23,8 @@ Step Client         MDT          OST
 2               <---LDLM_ENQUEUE
 //////////////////////////////////////////////////////////////////////
 
-1 - The client issues an LDLM_ENQUEUE with a 'getxattr' intent request
-to the MDS.
+*1 - The client issues an LDLM_ENQUEUE with a 'getxattr' intent
+request to the MDS.*
 
 The LDLM_ENQUEUE request identifies the resource, and asks for a
 protected read lock on the inode (LDLM_IBITS = 13) with a 'getxattr'
@@ -60,8 +57,10 @@ text art:
       -------------------------------------------------------
 //////////////////////////////////////////////////////////////////////
 
-2 - The MDT replies with an LDLM_ENQUEUE with the extended attributes
-data.
+See <<ldlm-enqueue-rpc>>.
+
+*2 - The MDT replies with an LDLM_ENQUEUE with the extended
+attributes data.*
 
 The LDLM_ENQUEUE reply grants the protected read lock on the inode
 bits. A 'struct mdt_body' (see <<struct-mdt-body>>) is present with no