LUDOC-297 protocol: Update protocol document

[doc/protocol.git] / struct_obd_connect_data.txt

diff --git a/struct_obd_connect_data.txt b/struct_obd_connect_data.txt
index ec0ccf7..2e2a792 100644 (file)
--- a/struct_obd_connect_data.txt
+++ b/struct_obd_connect_data.txt
@@ -1,20 +1,13 @@
 OBD Connect Data
 ^^^^^^^^^^^^^^^^
 OBD Connect Data
 ^^^^^^^^^^^^^^^^

-[[struct-obd-connect-data]]
-

 An 'obd_connect_data' structure accompanies every connect operation in
 both the request message and in the reply message.  It contains the
 mutually supported features that are negotiated between the client and
 server at *_CONNECT time.
 
 An 'obd_connect_data' structure accompanies every connect operation in
 both the request message and in the reply message.  It contains the
 mutually supported features that are negotiated between the client and
 server at *_CONNECT time.
 

-At *_CONNECT time the client sends in its request 'ocd_connect_flags'
-the flags for all features that it understands and intends to use (for
-example 'OBD_CONNECT_RDONLY' is optional depending on client mount
-options).  The request also contains other fields that are only valid
-if the matching flag is set.  The server replies in 'ocd_connect_flags'
-with the subset of feature flags that it understands and intends to honour.
-The server may set fields in the reply for mutually-understood features.
-
+.The OBD Connect Data Structure
+[[struct-obd-connect-data]]
+****

 [source,c]
 ----
 struct obd_connect_data {
 [source,c]
 ----
 struct obd_connect_data {


@@ -51,6 +44,15 @@ struct obd_connect_data {
     __u64 paddingF;
 };
 ----
     __u64 paddingF;
 };
 ----

+****
+
+At *_CONNECT time the client sends in its request 'ocd_connect_flags'
+the flags for all features that it understands and intends to use (for
+example 'OBD_CONNECT_RDONLY' is optional depending on client mount
+options).  The request also contains other fields that are only valid
+if the matching flag is set.  The server replies in 'ocd_connect_flags'
+with the subset of feature flags that it understands and intends to honour.
+The server may set fields in the reply for mutually-understood features.

 
 The 'ocd_connect_flags' field encodes the connect flags giving the
 capabilities of a connection between client and target. Several of
 
 The 'ocd_connect_flags' field encodes the connect flags giving the
 capabilities of a connection between client and target. Several of


@@ -124,20 +126,23 @@ specific target. This tells the server what capabilities it has. The
 server then replies with the subset of those capabilities it agrees to
 honor (for the given target).
 
 server then replies with the subset of those capabilities it agrees to
 honor (for the given target).
 

-If the 'OBD_CONNECT_VERSION' flag is set then the 'ocd_version' field is
-valid. The 'ocd_version' gives an encoding of the Lustre
-version. For example, Version 2.7.55 would be hexadecimal number
-0x02075500.
+If the 'OBD_CONNECT_VERSION' flag is set then the 'ocd_version' field
+is valid. The 'ocd_version' gives an encoding of the Lustre
+version. The Lustre version itself is a four-tuple of decimal numbers
+(major, minor, patch, fix), with missing trailing values defaulting to
+zero. Each of the four numbers is shifted into place in the four bytes
+of the 'ocd_version'.  For example, Version 2.7.55 would be
+hexadecimal number 0x02073700.

 
 If the OBD_CONNECT_GRANT flag is set then the 'ocd_grant' field is
 valid. The 'ocd_grant' value in a reply (to a connection request)
 
 If the OBD_CONNECT_GRANT flag is set then the 'ocd_grant' field is
 valid. The 'ocd_grant' value in a reply (to a connection request)

-sets the client's grant.
+initializes the client's grant. See <<grant>>.

 
 If the OBD_CONNECT_INDEX flag is set then the 'ocd_index' field is
 valid. The 'ocd_index' value is set in a request to hold the LOV
 
 If the OBD_CONNECT_INDEX flag is set then the 'ocd_index' field is
 valid. The 'ocd_index' value is set in a request to hold the LOV

-index of the OST or the LMV index of the MDT.  The server should
-refuse connections to targets for which the 'ocd_index' does not
-match the actual target index.
+index of the OST or the LMV index of the MDT.  The server's export for
+the target holds the correct value, and if the client send a value
+that does not match the server returns the -EBDF error.

 
 If the OBD_CONNECT_BRW_SIZE flag is set then the 'ocd_brw_size' field
 is valid. The 'ocd_brw_size' value sets the maximum supported bulk
 
 If the OBD_CONNECT_BRW_SIZE flag is set then the 'ocd_brw_size' field
 is valid. The 'ocd_brw_size' value sets the maximum supported bulk


@@ -149,9 +154,7 @@ requested maximum bulk transfer size.
 If the OBD_CONNECT_IBITS flag is set then the 'ocd_ibits_known' field
 is valid. The 'ocd_ibits_known' flags determine the handling of
 locks on MDS inodes.  The OBD_CONNECT_IBITS flag was introduced in
 If the OBD_CONNECT_IBITS flag is set then the 'ocd_ibits_known' field
 is valid. The 'ocd_ibits_known' flags determine the handling of
 locks on MDS inodes.  The OBD_CONNECT_IBITS flag was introduced in

-Lustre 1.4 and is mandatory for MDS_CONNECT RPCs. See also the discussion
-of inodes and extended attributes.
-[[mds-inode-bits-locks]]
+Lustre 1.4 and is mandatory for MDS_CONNECT RPCs.

 
 [source,c]
 ----
 
 [source,c]
 ----


@@ -187,13 +190,13 @@ base two of the size in bytes of the backend file system's blocks.
 A server reply uses the 'ocd_inodespace' value to inform the client of
 the log base two of the size of an inode.
 
 A server reply uses the 'ocd_inodespace' value to inform the client of
 the log base two of the size of an inode.
 

-Under some circumstances (for example when ZFS is the back end file
-system) there may be additional overhead in handling writes for each
-extent. The server uses the 'ocd_grant_extent' value to inform the
-client of the size in bytes consumed from its grant on the server when
-creating a new file. The client uses this value in calculating how
-much dirty write cache it has and whether it has reached the limit
-established by the target's grant.
+Under some circumstances (for example when the OSD is ZFS) there may
+be additional overhead in handling writes for each extent. The server
+uses the 'ocd_grant_extent' value to inform the client of the size in
+bytes consumed from its grant on the server when creating a new
+file. The client uses this value in calculating how much dirty write
+cache it has and whether it has reached the limit established by the
+target's grant.

 
 If the OBD_CONNECT_TRANSNO flag is set then the 'ocd_transno' field is
 honored. A server uses the 'ocd_transno' value during recovery to
 
 If the OBD_CONNECT_TRANSNO flag is set then the 'ocd_transno' field is
 honored. A server uses the 'ocd_transno' value during recovery to