LUDOC-297 protocol: Update protocol document

[doc/protocol.git] / setattr.txt

diff --git a/setattr.txt b/setattr.txt
index c2718f9..587e985 100644 (file)
--- a/setattr.txt
+++ b/setattr.txt
@@ -47,6 +47,8 @@ The mds-reint-setattr-request.png diagram resembles this text art:
       ------------------------------------------------
 //////////////////////////////////////////////////////////////////////
 
+See <<mds-reint-rpc>>.
+
 In this case the 'setattr' wants to set the mode attribute on
 the resource. The 'mdt_rec_setattr' identifies the resource with the
 'sa_fid' field, and the 'sa_valid' field is set to 0x2041:
@@ -113,7 +115,7 @@ Changing the File Time Attributes
 The RPC(s) that get sent for the 'setattr' depend on specifically what
 values are being set. If the time values are being set (as in a
 "touch" command) then there are RPCs in addition to the MDS_REINT,
-with the REINT_SETATTR sub-operation, that update the time vales on
+with the REINT_SETATTR sub-operation, that update the time values on
 the MDT. That operation is followed by an OST_SETATTR that sets the
 time values on the OST (or OSTs if there are several). But in order to
 know what OSTs to contact the client must first get the layout of the
@@ -142,6 +144,8 @@ Step Client         MDT           OST
 *1 - The client issues an MDS_REINT with the REINT_SETATTR
  sub-operation.*
 
+See <<mds-reint-rpc>>.
+
 The MDS_REINT request RPC closely resembles the one described above,
 but in this case the 'setattr' wants to set the time attributes on the
 resource. The 'mdt_rec_setattr' again identifies the resource with the
@@ -192,6 +196,8 @@ art:
       -----------------------------------------------------------
 //////////////////////////////////////////////////////////////////////
 
+See <<ldlm-enqueue-rpc>>.
+
 The 'ldlm_request' asks for a read lock on the resource and has its
 intent flag set. The 'ldlm_intent' has the intent opcode is 0x800:
 IT_LAYOUT. The 'layout_intent' has the 'li_opc' value 0:
@@ -235,9 +241,11 @@ The ost-setattr-request.png diagram resembles this text art:
       --------------------------
 //////////////////////////////////////////////////////////////////////
 
-The 'ost_body' structure is documented in <<struct-ost-body>>.  In
-this case the 'o_valid' field is 0x300400f, so the valid fields are
-given by:
+See <<ost-setattr-rpc>>.
+
+The 'ost_body' structure is documented in the <<struct-ost-body>>
+section.  In this case the 'o_valid' field is 0x300400f, so the valid
+fields are given by:
 
 .Flags for 'o_valid' field of 'struct os_body'
 [options="header"]
@@ -326,7 +334,7 @@ Step Client1         MDT           OST             Client2
 7                                          <--------LDLM_CANCEL
 8                   <-----------LDLM_CP_CALLBACK
 9    LDLM_CP_CALLBACK----------->
-10    OST_PUNCH-------------------->
+10   OST_PUNCH-------------------->
 11                                LDLM_CANCEL------>
 12           <--------------------OST_PUNCH
 //////////////////////////////////////////////////////////////////////
@@ -334,6 +342,8 @@ Step Client1         MDT           OST             Client2
 *1 - The client issues an MDS_REINT with the REINT_SETATTR
 sub-operation.*
 
+See <<mds-reint-rpc>>.
+
 The MDS_REINT request RPC closely resembles the one described above,
 but in this case the 'setattr' wants to modify the size attribute on the
 resource. The 'mdt_rec_setattr' again identifies the resource with the
@@ -364,6 +374,8 @@ including which valid attributes it echoes back.
 
 *3 - The client asks the OST for a write lock of type LDLM_EXTENT.*
 
+See <<ldlm-enqueue-rpc>>.
+
 The 'ldlm_request' asks for a write lock with the lock descriptor
 resource's type set to LDLM_EXTENT, the policy data covering the whole
 file, and the lock handle set to identify this request. The rest of
@@ -390,6 +402,8 @@ art:
       ------------------------------
 //////////////////////////////////////////////////////////////////////
 
+See <<ldlm-bl-callback-rpc>>.
+
 *5 - Client2 acknowledges the request and returns the lock.*
 
 The LDLM_BL_CALLBACK is an "empty" RPC in that it only has the
@@ -451,6 +465,8 @@ The ldlm-cancel-request.png diagram resembles this text art:
       ------------------------------
 //////////////////////////////////////////////////////////////////////
 
+See <<ldlm-cancel-rpc>>.
+
 The 'ldlm_request' indicates which lock is being canceled in its
 (first) 'lock_handle' field. The OST then looks for anyone else
 waiting on that lock, which it finds is Client1. It waits to reply to
@@ -475,6 +491,8 @@ art:
       ----------------------------------------
 //////////////////////////////////////////////////////////////////////
 
+See <<ldlm-cp-callback-rpc>>.
+
 *9 - Client1 acknowledges the lock update.*
 
 The reply is "empty" in this case as well. The opcode in the
@@ -510,6 +528,8 @@ The ost-punch-request.png diagram resembles this text art:
       --------------------------
 //////////////////////////////////////////////////////////////////////
 
+See <<ost-punch-rpc>>.
+
 In this case the 'o_valid' field is 0x30403d:
 
 .Flags for 'o_valid' field of 'struct os_body'