getxattr.txt

   1 Getxattr
   2 ~~~~~~~~
   3
   4 The 'getxattr' VFS method queries extended attribute information for a
   5 resource given a path ('getxattr()' system call) or FID ('fgetxattr()'
   6 system call). If provided a path Lustre will go through a path lookup
   7 first (not shown [fixme: this should be a cross reference]) in order
   8 to determine the FID for the resource.
   9
  10 Lustre maintains extended attribute information on the MDS, and a
  11 single RPC (request and reply) retrieves the information from the
  12 MDT. The RPC is an LDLM_ENQUEUE with the 'getxattr' intent. The RPC is
  13 shown in <<getxattr-rpcs>>.
  14
  15 .Getxattr RPCs
  16 [[getxattr-rpcs]]
  17 image::getxattr_rpcs.png["getxattr RPCs",height=75]
  18
  19 //////////////////////////////////////////////////////////////////////
  20 The getxattr_rpcs.png diagram resembles this text art:
  21
  22 Time
  23 Step Client         MDT          OST
  24      -------        -------      -------
  25 1    LDLM_ENQUEUE--->
  26 2               <---LDLM_ENQUEUE
  27 //////////////////////////////////////////////////////////////////////
  28
  29 *1 - The client issues an LDLM_ENQUEUE with a 'getxattr' intent
  30 request to the MDS.*
  31
  32 The LDLM_ENQUEUE request identifies the resource, and asks for a
  33 protected read lock on the inode (LDLM_IBITS = 13) with a 'getxattr'
  34 intent. It accompanies the request with a 'struct mdt_body' that
  35 provides the FID. The 'mbo_valid' field of the 'mdt_body' is
  36 0x3000000001 which corresponds to these flags:
  37
  38 .Flags for 'mbo_valid' field of 'struct mdt_body'
  39 [options="header"]
  40 |====
  41 | Flag                | Meaning
  42 | OBD_MD_FLID         | FID
  43 | OBD_MD_FLXATTR      | extended attributes
  44 | OBD_MD_FLXATTRLS    | extended attributes size
  45 |====
  46
  47 The inclusion of OBD_MD_FLXATTR and OBD_MD_FLXATTRLS indicate that the
  48 extended attributes are the information being requested for the FID.
  49
  50 .LDLM_ENQUEUE Intent:Getxattr Request Packet Structure
  51 image::ldlm-enqueue-intent-getxattr-request.png["LDLM_ENQUEUE Intent:Getxattr Request Packet Structure",height=50]
  52
  53 //////////////////////////////////////////////////////////////////////
  54 The ldlm-enqueue-intent-getxattr-request.png diagram resembles this
  55 text art:
  56
  57         LDLM_ENQUEUE:
  58       --intent:getxattr request------------------------------
  59       | ptlrpc_body | ldlm_request | ldlm_intent | mdt_body |
  60       -------------------------------------------------------
  61 //////////////////////////////////////////////////////////////////////
  62
  63 *2 - The MDT replies with an LDLM_ENQUEUE with the extended
  64 attributes data.*
  65
  66 The LDLM_ENQUEUE reply grants the protected read lock on the inode
  67 bits. A 'struct mdt_body' (see <<struct-mdt-body>>) is present with no
  68 valid metadata ('mbo_valid' = 0), but the 'mbo_eadatasize',
  69 'mbo_aclsize', and 'mb_maxmdsize' fields are valid. Those values give
  70 the sizes of the 'EA data' and 'EA vals' buffers, respectively, and
  71 the number of (__u32) entries in the 'EA lens' array. The 'struct
  72 lov_mds_md' and the ACL data are also present but carry no
  73 information.
  74
  75 .LDLM_ENQUEUE Intent:Getxattr Reply Packet Structure
  76 image::ldlm-enqueue-intent-getxattr-reply.png["LDLM_ENQUEUE Intent:Getxattr Reply Packet Structure",height=80]
  77
  78 //////////////////////////////////////////////////////////////////////
  79 The ldlm-enqueue-intent-getxattr-reply.png diagram resembles this
  80 text art:
  81
  82         LDLM_ENQUEUE:
  83       --intent:getxattr reply----------------------------------------
  84       | ptlrpc_body | ldlm_reply | mdt_body | lov_mds_md | ACL data |
  85       | EA data | EA vals | EA lens |
  86       ---------------------------------------------------------------
  87 //////////////////////////////////////////////////////////////////////
  88
  89 The last three sections of the message convey the extended attributes
  90 information. They are formed as follow: The "EA data" section lists a
  91 sequence of null-terminated strings, where each string identifies an
  92 extended attribute. The "EA vals" section is a block of data holding
  93 the values of the listed extended attributes. The "EA lens" section is
  94 an array of sizes (__u32). Each of those sizes gives the length of the
  95 EA value, in order, in the "EA values" block.
  96
  97