Whamcloud - gitweb
LUDOC-296 protocol: remove internal details from descriptions
[doc/protocol.git] / ldlm_enqueue.txt
index f1e029c..aa36ad6 100644 (file)
@@ -1,5 +1,5 @@
-Command 101: LDLM ENQUEUE - Enqueue a lock request
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+RPC 101: LDLM ENQUEUE - Enqueue a lock request
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 [[ldlm-enqueue-rpc]]
 
 An RPC that implements distributed locking across the servers and
@@ -87,14 +87,15 @@ art:
 //////////////////////////////////////////////////////////////////////
 
 'ptlrpc_body'::
-RPC descriptor.
+RPC descriptor <<struct-ptlrpc-body>>.
 
 'ldlm_request'::
 Description of the lock being requested. Which resource is the target,
-what lock is current, and what lock desired.
+what lock is current, and what lock desired. <<struct-ldlm-request>>
 
 'ldlm_intent'::
 Description of the intent being included with the lock request.
+<<struct-ldlm-intent>>
 
 'layout_intent'::
 Description of the layout information that is the subject of a layout
@@ -103,7 +104,7 @@ intent.
 'mdt_body'::
 In a request, an indication (in the 'mbo_valid' field) of what
 attributes the requester would like. In a reply, (again based on
-'mbo_valid') the values being returned.
+'mbo_valid') the values being returned. <<struct-mdt-body>>
 
 'lustre_capa'::
 So called "capabilities" structure. This is deprecated in recent
@@ -115,14 +116,10 @@ A text field supplying the name of the desired resource.
 
 'ldlm_reply'::
 Resembling the 'ldlm_request', but in this case indicating what the
-LDLM actually granted as well as relevant policy data.
-
-'mdt_md'::
-Layout data for the resource. This buffer is optional and will appear
-as zero length in some packets.
+LDLM actually granted as well as relevant policy data. <<struct-ldlm-reply>>
 
 'mdt_body'::
-Metadata about a given resource.
+Metadata about a given resource. <<struct-mdt-body>>
 
 'ACL data'::
 Access Control List data associated with a resource.
@@ -146,18 +143,18 @@ Lock Value Block::
 A Lock Value Block (LVB) is included in the LDLM_ENQUEUE reply message
 when one of three things needs to be communicated back to the
 requester. The three alternatives are captured by the
-'ost_lvb'structure, the 'lov_mds_md' structure, and one other related
+'ost_lvb' structure, the 'lov_mds_md' structure, and one other related
 to quotas (and not yet incorporated into this document). LDLM_ENQUEUE
 reply RPCs may include a zero length instance of an LVB.
 
 'ost_lvb'::
 An LVB to communicate attribute data for an extent associated with a
 resource on a lock. It is returned from an OST to a client requesting
-an extent lock.
+an extent lock. <<struct-ost-lvb>>
 
 'lov_mds_md'::
-An LVB to communicate layout data associated with a resource. It is
+Layout data associated with a resource. It is
 returned from an MDT to a client requesting a lock a lock with a
 layout intent. In an intent request (as opposed to a reply and as yet
 unimplemanted) it will modify the layout. It will not be included
-(zero length) in requests in current releases.
+(zero length) in requests in current releases. <<struct-lov-mds-md>>