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.
9 Examining the File Attributes
10 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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>>.
16 .Getattr RPCs for Examining File Attributes
18 image::fstat_rpcs.png["getattr RPCs for examining file attributes",height=150]
20 //////////////////////////////////////////////////////////////////////
21 The fstat_rpcs.png diagram resembles this text art:
24 Step Client1 MDT OST Client2
25 ------- ------- ------- -------
27 2 <-------LDLM_ENQUEUE
28 3 LDLM_ENQUEUE----------------->
29 4 LDLM_GL_CALLBACK---->
30 5 <-------LDLM_GL_CALLBACK
31 6 <-----------------LDLM_ENQUEUE
32 //////////////////////////////////////////////////////////////////////
34 *1 - Client1 issues an LDLM_ENQUEUE with a GETATTR intent.*
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.
39 //////////////////////////////////////////////////////////////////////
40 Add this cross reference once we rebased to the setattr update.
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
46 //////////////////////////////////////////////////////////////////////
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]
51 //////////////////////////////////////////////////////////////////////
52 The ldlm-enqueue-intent-getattr-request.png diagram resembles this
56 --intent:getattr request--------------------------------------
57 | ptlrpc_body | ldlm_request | ldlm_intent | mdt_body | name |
58 --------------------------------------------------------------
59 //////////////////////////////////////////////////////////////////////
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.
65 The 'ldlm_intent' opcode is for 'getattr' (0x1000).
67 The 'mdt_body' has its 'mbo_valid' field set to 0x28491035fdf, which
70 .Flags for 'mbo_valid' field of 'struct mdt_body'
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
93 | OBD_MD_FLACL | access control list (ACL)
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
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.
106 *2 - The LDLM_ENQUEUE reply returns the indicated attribute values to
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.
113 //////////////////////////////////////////////////////////////////////
114 Add this cross reference once we rebased to the setattr update.
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 //////////////////////////////////////////////////////////////////////
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]
124 //////////////////////////////////////////////////////////////////////
125 The ldlm-enqueue-intent-getattr-reply.png diagram resembles this text
129 --intent:getattr reply--------------------------
130 | ptlrpc_body | ldlm_reply | mdt_body | mdt_md |
131 ------------------------------------------------
132 //////////////////////////////////////////////////////////////////////
134 The reply from the MDT grants the requested concurrent read lock on
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):
141 .Flags for 'mbo_valid' field of 'struct mdt_body'
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 |
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).
164 *3 - Client1 asks for a protected read lock on the resource on the
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).
172 .LDLM_ENQUEUE Request Packet Structure
173 image::ldlm-enqueue-request.png["LDLM_ENQUEUE Request Packet Structure",height=50]
175 //////////////////////////////////////////////////////////////////////
176 The ldlm-enqueue-request.png diagram resembles this text art:
179 --request---------------------
180 | ptlrpc_body | ldlm_request |
181 ------------------------------
182 //////////////////////////////////////////////////////////////////////
184 *4 - The OST invokes a glimps lock callback on Client2.*
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.
191 .LDLM_GL_CALLBACK Request Packet Structure
192 image::ldlm-gl-callback-request.png["LDLM_GL_CALLBACK Request Packet Structure",height=50]
194 //////////////////////////////////////////////////////////////////////
195 The ldlm-gl-callback-request.png diagram resembles this text art:
198 --request---------------------
199 | ptlrpc_body | ldlm_request |
200 ------------------------------
201 //////////////////////////////////////////////////////////////////////
203 *5 - Client2 replies with LVB data for the OST.*
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.
210 .LDLM_GL_CALLBACK Reply Packet Structure
211 image::ldlm-gl-callback-reply.png["LDLM_GL_CALLBACK Reply Packet Structure",height=50]
213 //////////////////////////////////////////////////////////////////////
214 The ldlm-gl-callback-reply.png diagram resembles this text art:
217 --reply------------------
218 | ptlrpc_body | ost_lvb |
219 -------------------------
220 //////////////////////////////////////////////////////////////////////
222 The 'ost_lvb' data from Client2 has atribute data to update the OST.
224 *6 - The OST replies with the updated attribute information.*
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]
229 //////////////////////////////////////////////////////////////////////
230 The ldlm-enqueue-intent-lvb-reply.png diagram resembles this text art:
233 --intent:lvb reply--------------------
234 | ptlrpc_body | ldlm_reply | ost_lvb |
235 --------------------------------------
236 //////////////////////////////////////////////////////////////////////
238 The lock is not granted, but the attribute data has been updated.