LUDOC-276 protocol: Document RPCs for setattr

[doc/protocol.git] / lustre_operations.txt

diff --git a/lustre_operations.txt b/lustre_operations.txt
index 96ff8d3..c8c3ab4 100644 (file)
--- a/lustre_operations.txt
+++ b/lustre_operations.txt
@@ -12,6 +12,8 @@ any. See the discussion on <<transno,transaction numbers>>
 and <<recovery>> for how the client is given confirmation that a
 request has been completed.
 
+include::ost_setattr.txt[]
+
 Command 8: OST CONNECT - Client connection to an OST
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -71,6 +73,8 @@ Command 9: OST DISCONNECT - Disconnect client from an OST
 The information exchanged in a DISCONNECT message is that normally
 conveyed in the mesage preamble.
 
+include::ost_punch.txt[]
+
 Command 33: MDS GETATTR - Get MDS Attributes
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -82,6 +86,7 @@ Command 33: MDS GETATTR - Get MDS Attributes
 |====
 
 
+include::mds_reint.txt[]
 
 Command 38: MDS CONNECT - Client connection to an MDS
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -153,7 +158,7 @@ Command 40: MDS GETSTATUS - get the status from a target
 The MDS_GETSTATUS command targets a specific MDT. If there are several,
 the client will need to send a separate message for each.
 
-.MDS_GETSTATUS (41)
+.MDS_GETSTATUS (40)
 [options="header"]
 |====
 | request       | reply
@@ -184,55 +189,15 @@ this client, with 'pb_opc' being set to MDS_STATFS (41).
 In the reply there is, in addition to the 'ptlrpc_body', data relevant
 to a 'statfs' system call.
 
-Command 101: LDLM ENQUEUE - Enqueue a lock request
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-.LDLM_ENQUEUE (101)
-[options="header"]
-|====
-| request            | reply
-| ldlm_enqueue_client | ldlm_enqueue_lvb_server
-|====
-
-In order to access data on disk at a target the client needs to
-establish a lock (either concurrent for reads or exclusive for
-writes).  The client sends the 'ldlm_enqueue_client' message to the
-server holding the target, and the server will reply with an
-'ldlm_enqueue_server' message. (N.B. It actuallity it is an
-'ldlm_enqueue_lvb_server' message with the length of the 'struct
-ost_lvb' portion set to zero, which ammounts to the same thing).
-
-The target UUID is just "MGS", and the client UUID is set to the
-32byte string it gets from ... where?
-
-The 'struct lustre_handle' (the fourth buffer in the message) has its
-cookie set to .. what? It is set, but where does it come from?
-
-The 'ocd_connect_flags' field is set to (fixme: what?) reflecting the
-capabilities appropriate to the client. The 'ocd_brw_size' is set to the
-largest value for the size of an RPC that the client can handle. The
-'ocd_ibits_known' and 'ocd_checksum_types' values are set to what the client
-considers appropriate. Other fields in the preamble and
-'obd_connect_data' structures are zero.
+include::mds_getxattr.txt[]
 
-Once the server receives the 'obd_connect_client' message on behalf of
-the given target it replies with an 'obd_connect_server' message. In
-that message the server sends the 'pb__handle' to uniquely
-identify the connection for subsequent communication. The client notes
-that handle in its import for the given target.
+include::ldlm_enqueue.txt[]
 
-fixme: Are there circumstances that could lead to the 'status'
-value in the reply being non-zero? What would lead to that and what
-error values would result?
+include::ldlm_cancel.txt[]
 
-The target maintains the last committed transaction for a client in
-its export for that client. If this is the first connection, then that
-last transactiion value would just be zero. If there were previous
-transactions for the client, then the transaction number for the last
-such committed transaction is put in the 'pb_last_committed' field.
+include::ldlm_bl_callback.txt[]
 
-In a connection request the operation is not file system modifying, so
-the 'pb_transno' value will be zero in the reply as well.
+include::ldlm_cp_callback.txt[]
 
 Command 250: MGS CONNECT - Client connection to an MGS
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~