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