X-Git-Url: https://git.whamcloud.com/?a=blobdiff_plain;f=struct_obd_connect_data.txt;fp=struct_obd_connect_data.txt;h=2e2a792498cf350138c5e860a17afd171b9071b6;hb=fcef7c1bf5a197eed7a85704be12b80c5067c2d1;hp=ec0ccf784b042f54c3794b419a7bd91e8561ea9b;hpb=a35c4d03a85eaab5762e11b54ed982bb9f74e5cb;p=doc%2Fprotocol.git diff --git a/struct_obd_connect_data.txt b/struct_obd_connect_data.txt index ec0ccf7..2e2a792 100644 --- a/struct_obd_connect_data.txt +++ b/struct_obd_connect_data.txt @@ -1,20 +1,13 @@ 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. -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 { @@ -51,6 +44,15 @@ struct obd_connect_data { __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 @@ -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). -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) -sets the client's grant. +initializes the client's grant. See <>. 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 @@ -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 -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] ---- @@ -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. -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