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 See <<ldlm-enqueue-rpc>>.
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>>).
67 The 'ldlm_intent' opcode is for 'getattr' (0x1000).
69 The 'mdt_body' has its 'mbo_valid' field set to 0x28491035fdf, which
72 .Flags for 'mbo_valid' field of 'struct mdt_body'
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
95 | OBD_MD_FLACL | access control list (ACL)
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
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.
108 *2 - The LDLM_ENQUEUE reply returns the indicated attribute values to
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.
115 //////////////////////////////////////////////////////////////////////
116 Add this cross reference once we rebased to the setattr update.
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 //////////////////////////////////////////////////////////////////////
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]
126 //////////////////////////////////////////////////////////////////////
127 The ldlm-enqueue-intent-getattr-reply.png diagram resembles this text
131 --intent:getattr reply--------------------------
132 | ptlrpc_body | ldlm_reply | mdt_body | mdt_md |
133 ------------------------------------------------
134 //////////////////////////////////////////////////////////////////////
136 The reply from the MDT grants the requested concurrent read lock on
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):
143 .Flags for 'mbo_valid' field of 'struct mdt_body'
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 |
162 As a bonus the MDT returns 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).
166 *3 - Client1 asks for a protected read lock on the resource on the
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).
174 .LDLM_ENQUEUE Request Packet Structure
175 image::ldlm-enqueue-request.png["LDLM_ENQUEUE Request Packet Structure",height=50]
177 //////////////////////////////////////////////////////////////////////
178 The ldlm-enqueue-request.png diagram resembles this text art:
181 --request---------------------
182 | ptlrpc_body | ldlm_request |
183 ------------------------------
184 //////////////////////////////////////////////////////////////////////
186 See <<ldlm-enqueue-rpc>>.
188 *4 - The OST invokes a glimpse lock callback on Client2.*
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.
195 .LDLM_GL_CALLBACK Request Packet Structure
196 image::ldlm-gl-callback-request.png["LDLM_GL_CALLBACK Request Packet Structure",height=50]
198 //////////////////////////////////////////////////////////////////////
199 The ldlm-gl-callback-request.png diagram resembles this text art:
202 --request---------------------
203 | ptlrpc_body | ldlm_request |
204 ------------------------------
205 //////////////////////////////////////////////////////////////////////
207 See <<ldlm-gl-callback-rpc>>.
209 *5 - Client2 replies with LVB data for the OST.*
211 The OST is waiting to hear back from Client2 to update size and time
212 attributes, if needed, due to Client2 cache 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.
216 .LDLM_GL_CALLBACK Reply Packet Structure
217 image::ldlm-gl-callback-reply.png["LDLM_GL_CALLBACK Reply Packet Structure",height=50]
219 //////////////////////////////////////////////////////////////////////
220 The ldlm-gl-callback-reply.png diagram resembles this text art:
223 --reply------------------
224 | ptlrpc_body | ost_lvb |
225 -------------------------
226 //////////////////////////////////////////////////////////////////////
228 The 'ost_lvb' data from Client2 has attribute data to update the OST.
230 *6 - The OST replies with the updated attribute information.*
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]
235 //////////////////////////////////////////////////////////////////////
236 The ldlm-enqueue-intent-lvb-reply.png diagram resembles this text art:
239 --intent:lvb reply--------------------
240 | ptlrpc_body | ldlm_reply | ost_lvb |
241 --------------------------------------
242 //////////////////////////////////////////////////////////////////////
244 The lock is not granted, but the attribute data has been updated.