getattr.txt

   1 Getattr
   2 ~~~~~~~
   3 [[getattr]]
   4 The 'getattr' VFS method is used to examine the attributes associated
   5 with a resource (it is an inode operation). The attributes are the
   6 same ones returned by a 'stat' operation: mode, uid, guid, size,
   7 atime, ctime, and mtime.
   8
   9 Examining the File Attributes
  10 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  11
  12 When file attribute information is requested (a 'stat' command or
  13 'fstat' system call, for instance) the 'getattr' is part of the
  14 interaction with the LDLM. The RPCs are as shown in <<fstat-rpcs>>.
  15
  16 .Getattr RPCs for Examining File Attributes
  17 [[fstat-rpcs]]
  18 image::fstat_rpcs.png["getattr RPCs for examining file attributes",height=150]
  19
  20 //////////////////////////////////////////////////////////////////////
  21 The fstat_rpcs.png diagram resembles this text art:
  22
  23 Time
  24 Step Client1         MDT           OST             Client2
  25      -------         -------      -------          -------
  26 1    LDLM_ENQUEUE---->
  27 2            <-------LDLM_ENQUEUE
  28 3    LDLM_ENQUEUE----------------->
  29 4                               LDLM_GL_CALLBACK---->
  30 5                                           <-------LDLM_GL_CALLBACK
  31 6               <-----------------LDLM_ENQUEUE
  32 //////////////////////////////////////////////////////////////////////
  33
  34 *1 - Client1 issues an LDLM_ENQUEUE with a GETATTR intent.*
  35
  36 The LDLM_ENQUEUE request RPC asks for a concurrent read lock on the
  37 resource and indicates the values it is interested in receiving.
  38
  39 //////////////////////////////////////////////////////////////////////
  40 Add this cross reference once we rebased to the setattr update.
  41
  42 For a detailed discussion of all the fields in
  43 the 'ldlm_request', 'ldlm_intent', and 'mdt_body' refer to
  44 <<struct-ldlm-request>>, <<struct-ldlm-intent>>, and
  45 <<struct-mdt-body>>.
  46 //////////////////////////////////////////////////////////////////////
  47
  48 .LDLM_ENQUEUE ( intent : getattr ) Request Packet Structure
  49 image::ldlm-enqueue-intent-getattr-request.png["LDLM_ENQUEUE (intent : getattr) Request Packet Structure",height=50]
  50
  51 //////////////////////////////////////////////////////////////////////
  52 The ldlm-enqueue-intent-getattr-request.png diagram resembles this
  53 text art:
  54
  55         LDLM_ENQUEUE:
  56       --intent:getattr request--------------------------------------
  57       | ptlrpc_body | ldlm_request | ldlm_intent | mdt_body | name |
  58       --------------------------------------------------------------
  59 //////////////////////////////////////////////////////////////////////
  60
  61 The ldlm_request structure signals that it has an intent ('lock_flags' =
  62 LDLM_FL_HAS_INTENT), The lock descriptor's resource type is
  63 'loc_desc'->'l_resource'->'lr_type'=LDLM_IBITS.
  64
  65 The 'ldlm_intent' opcode is for 'getattr' (0x1000).
  66
  67 The 'mdt_body' has its 'mbo_valid' field set to 0x28491035fdf, which
  68 is these flags:
  69
  70 .Flags for 'mbo_valid' field of 'struct mdt_body'
  71 [options="header"]
  72 |====
  73 | Flag               | Meaning
  74 | OBD_MD_FLID        | FID
  75 | OBD_MD_FLATIME     | atime attribute
  76 | OBD_MD_FLMTIME     | mtime attribute
  77 | OBD_MD_FLCTIME     | ctime attribute
  78 | OBD_MD_FLSIZE      | size attribute
  79 | OBD_MD_FLBLKSZ     | block size attribute
  80 | OBD_MD_FLMODE      | mode attribute
  81 | OBD_MD_FLTYPE      | type
  82 | OBD_MD_FLUID       | UID attribute
  83 | OBD_MD_FLGID       | GID attribute
  84 | OBD_MD_FLFLAGS     | flags
  85 | OBD_MD_FLNLINK     | number of links
  86 | OBD_MD_FLGENER     | generation
  87 | OBD_MD_FLRDEV      | rdev
  88 | OBD_MD_FLEASIZE    | extended attributes size
  89 | OBD_MD_FLGROUP     | group
  90 | OBD_MD_FLDIREA     | dir extended attributes
  91 | OBD_MD_FLMODEASIZE | mode size
  92 | OBD_MD_MEA         |
  93 | OBD_MD_FLACL       | access control list (ACL)
  94 | OBD_MD_FLMDSCAPA   |
  95 |====
  96
  97 In the context of an LDLM_ENQUEUE 'getattr' intent request the flags
  98 indicate that Client1 would like to hear back about the flagged
  99 attributes.
 100
 101 The 'name' buffer is one byte long in this case. That signifies an
 102 empty string ('\0'). The resource was identified by FID in this case,
 103 but in other circumstances it might be identified by name via a string
 104 value in the last buffer.
 105
 106 *2 - The LDLM_ENQUEUE reply returns the indicated attribute values to
 107 Client1.*
 108
 109 In addition to the 'ptlrpc_body' (RPC message header), the
 110 LDLM_ENQUEUE reply RPC to Client1 has an 'ldlm_reply', an
 111 'mdt_body', and an 'mdt_md' structure.
 112
 113 //////////////////////////////////////////////////////////////////////
 114 Add this cross reference once we rebased to the setattr update.
 115
 116 For a detailed discussion of
 117 the fields in 'ldlm_reply', 'mdt_body', and 'mdt_md' refer to
 118 <<struct-ldlm-reply>>, <<struct-mdt-body>>, and <<struct-mdt-md>>.
 119 //////////////////////////////////////////////////////////////////////
 120
 121 .LDLM_ENQUEUE (intent : getattr ) Reply Packet Structure
 122 image::ldlm-enqueue-intent-getattr-reply.png["LDLM_ENQUEUE ( intent : getattr ) Reply Packet Structure",height=50]
 123
 124 //////////////////////////////////////////////////////////////////////
 125 The ldlm-enqueue-intent-getattr-reply.png diagram resembles this text
 126 art:
 127
 128       LDLM_ENQUEUE:
 129       --intent:getattr reply--------------------------
 130       | ptlrpc_body | ldlm_reply | mdt_body | mdt_md |
 131       ------------------------------------------------
 132 //////////////////////////////////////////////////////////////////////
 133
 134 The reply from the MDT grants the requested concurrent read lock on
 135 the resource.
 136
 137 The 'mdt_body' carries the 'getattr' attribute information that was
 138 being requested. The mbo_valid field indicates that it is replying
 139 with this set of valid fields (0x8080022f8f):
 140
 141 .Flags for 'mbo_valid' field of 'struct mdt_body'
 142 [options="header"]
 143 |====
 144 | Flag               | Meaning
 145 | OBD_MD_FLID        | FID
 146 | OBD_MD_FLATIME     | atime attribute
 147 | OBD_MD_FLMTIME     | mtime attribute
 148 | OBD_MD_FLCTIME     | ctime attribute
 149 | OBD_MD_FLMODE      | mode attribute
 150 | OBD_MD_FLTYPE      | type
 151 | OBD_MD_FLUID       | UID attribute
 152 | OBD_MD_FLGID       | GID attribute
 153 | OBD_MD_FLFLAGS     | flags
 154 | OBD_MD_FLNLINK     | number of links attribute
 155 | OBD_MD_FLEASIZE    | extended attributes size
 156 | OBD_MD_FLMODEASIZE |
 157 | OBD_MD_FLACL       | ACL
 158 |====
 159
 160 As a bonus the MDT returnes layout information about the file, so that
 161 Client1 can get attribute information from the OST(s) responsible
 162 for the file's objects (if any).
 163
 164 *3 - Client1 asks for a protected read lock on the resource on the
 165 OST.*
 166
 167 The previous RPC provided layout information to Client1 enabling it to
 168 query the OSTs (one of them in this case) about the object's
 169 attributes. The LDLM_ ENQUEUE indicates the desired (on-OST) resource
 170 and that it should be a protected read of type LDLM_EXTENT (11).
 171
 172 .LDLM_ENQUEUE Request Packet Structure
 173 image::ldlm-enqueue-request.png["LDLM_ENQUEUE Request Packet Structure",height=50]
 174
 175 //////////////////////////////////////////////////////////////////////
 176 The ldlm-enqueue-request.png diagram resembles this text art:
 177
 178        LDLM_ENQUEUE:
 179       --request---------------------
 180       | ptlrpc_body | ldlm_request |
 181       ------------------------------
 182 //////////////////////////////////////////////////////////////////////
 183
 184 *4 - The OST invokes a glimps lock callback on Client2.*
 185
 186 Client2 previously had a lock on the desired resource, and the glimpse
 187 induces Client2 to flush its buffers, if needed, and update the OST
 188 size and time attributes.  The LDLM_GL_CALLBACK asks for a write lock
 189 on the entire extent of the resource.
 190
 191 .LDLM_GL_CALLBACK Request Packet Structure
 192 image::ldlm-gl-callback-request.png["LDLM_GL_CALLBACK Request Packet Structure",height=50]
 193
 194 //////////////////////////////////////////////////////////////////////
 195 The ldlm-gl-callback-request.png diagram resembles this text art:
 196
 197        LDLM_GL_CALLBACK:
 198       --request---------------------
 199       | ptlrpc_body | ldlm_request |
 200       ------------------------------
 201 //////////////////////////////////////////////////////////////////////
 202
 203 *5 - Client2 replies with LVB data for the OST.*
 204
 205 The OST is waiting to hear back from Client2 to update size and time
 206 attributes, if needed, due to Client2 chache being flushed to the
 207 OST. The glimpse allows the information to return to the OST, and
 208 thereby get passed to Client1, without taking the lock from Client2.
 209
 210 .LDLM_GL_CALLBACK Reply Packet Structure
 211 image::ldlm-gl-callback-reply.png["LDLM_GL_CALLBACK Reply Packet Structure",height=50]
 212
 213 //////////////////////////////////////////////////////////////////////
 214 The ldlm-gl-callback-reply.png diagram resembles this text art:
 215
 216        LDLM_GL_CALLBACK:
 217       --reply------------------
 218       | ptlrpc_body | ost_lvb |
 219       -------------------------
 220 //////////////////////////////////////////////////////////////////////
 221
 222 The 'ost_lvb' data from Client2 has atribute data to update the OST.
 223
 224 *6 - The OST replies with the updated attribute information.*
 225
 226 .LDLM_ENQUEUE Intent:LVB Reply Packet Structure
 227 image::ldlm-enqueue-intent-lvb-reply.png["LDLM_ENQUEUE Intent:LVB Reply Packet Structure",height=50]
 228
 229 //////////////////////////////////////////////////////////////////////
 230 The ldlm-enqueue-intent-lvb-reply.png diagram resembles this text art:
 231
 232        LDLM_ENQUEUE:
 233       --intent:lvb reply--------------------
 234       | ptlrpc_body | ldlm_reply | ost_lvb |
 235       --------------------------------------
 236 //////////////////////////////////////////////////////////////////////
 237
 238 The lock is not granted, but the attribute data has been updated.