4 The 'getxattr' VFS method queries extended attribute information for a
7 Lustre maintains extended attribute information on the MDS, and a
8 single RPC (request and reply) retrieves the information from the
9 MDT. The RPC is an LDLM_ENQUEUE with the 'getxattr' intent. The RPC is
10 shown in <<getxattr-rpcs>>.
14 image::getxattr_rpcs.png["getxattr RPCs",height=75]
16 //////////////////////////////////////////////////////////////////////
17 The getxattr_rpcs.png diagram resembles this text art:
21 ------- ------- -------
24 //////////////////////////////////////////////////////////////////////
26 *1 - The client issues an LDLM_ENQUEUE with a 'getxattr' intent
29 The LDLM_ENQUEUE request identifies the resource, and asks for a
30 protected read lock on the inode (LDLM_IBITS = 13) with a 'getxattr'
31 intent. It accompanies the request with a 'struct mdt_body' that
32 provides the FID. The 'mbo_valid' field of the 'mdt_body' is
33 0x3000000001 which corresponds to these flags:
35 .Flags for 'mbo_valid' field of 'struct mdt_body'
40 | OBD_MD_FLXATTR | extended attributes
41 | OBD_MD_FLXATTRLS | extended attributes size
44 The inclusion of OBD_MD_FLXATTR and OBD_MD_FLXATTRLS indicate that the
45 extended attributes are the information being requested for the FID.
47 .LDLM_ENQUEUE Intent:Getxattr Request Packet Structure
48 image::ldlm-enqueue-intent-getxattr-request.png["LDLM_ENQUEUE Intent:Getxattr Request Packet Structure",height=50]
50 //////////////////////////////////////////////////////////////////////
51 The ldlm-enqueue-intent-getxattr-request.png diagram resembles this
55 --intent:getxattr request------------------------------
56 | ptlrpc_body | ldlm_request | ldlm_intent | mdt_body |
57 -------------------------------------------------------
58 //////////////////////////////////////////////////////////////////////
60 See <<ldlm-enqueue-rpc>>.
62 *2 - The MDT replies with an LDLM_ENQUEUE with the extended
65 The LDLM_ENQUEUE reply grants the protected read lock on the inode
66 bits. A 'struct mdt_body' (see <<struct-mdt-body>>) is present with no
67 valid metadata ('mbo_valid' = 0), but the 'mbo_eadatasize',
68 'mbo_aclsize', and 'mb_maxmdsize' fields are valid. Those values give
69 the sizes of the 'EA data' and 'EA vals' buffers, respectively, and
70 the number of (__u32) entries in the 'EA lens' array. The 'struct
71 lov_mds_md' and the ACL data are also present but carry no
74 .LDLM_ENQUEUE Intent:Getxattr Reply Packet Structure
75 image::ldlm-enqueue-intent-getxattr-reply.png["LDLM_ENQUEUE Intent:Getxattr Reply Packet Structure",height=80]
77 //////////////////////////////////////////////////////////////////////
78 The ldlm-enqueue-intent-getxattr-reply.png diagram resembles this
82 --intent:getxattr reply----------------------------------------
83 | ptlrpc_body | ldlm_reply | mdt_body | lov_mds_md | ACL data |
84 | EA data | EA vals | EA lens |
85 ---------------------------------------------------------------
86 //////////////////////////////////////////////////////////////////////
88 The last three sections of the message convey the extended attributes
89 information. They are formed as follow: The "EA data" section lists a
90 sequence of null-terminated strings, where each string identifies an
91 extended attribute. The "EA vals" section is a block of data holding
92 the values of the listed extended attributes. The "EA lens" section is
93 an array of sizes (__u32). Each of those sizes gives the length of the
94 EA value, in order, in the "EA values" block.