Getattr ~~~~~~~ The 'getattr' VFS method is used to examine the attributes associated with a resource (it is an inode operation). The attributes are the same ones returned by a 'stat' operation: mode, uid, guid, size, atime, ctime, and mtime. Examining the File Attributes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ When file attribute information is requested (a 'stat' command or 'fstat' system call, for instance) the 'getattr' is part of the interaction with the LDLM. The RPCs are as shown in <>. .Getattr RPCs for Examining File Attributes [[fstat-rpcs]] image::fstat_rpcs.png["getattr RPCs for examining file attributes",height=150] ////////////////////////////////////////////////////////////////////// The fstat_rpcs.png diagram resembles this text art: Time Step Client1 MDT OST Client2 ------- ------- ------- ------- 1 LDLM_ENQUEUE----> 2 <-------LDLM_ENQUEUE 3 LDLM_ENQUEUE-----------------> 4 LDLM_GL_CALLBACK----> 5 <-------LDLM_GL_CALLBACK 6 <-----------------LDLM_ENQUEUE ////////////////////////////////////////////////////////////////////// 1 - Client1 issues an LDLM_ENQUEUE with a GETATTR intent. The LDLM_ENQUEUE request RPC asks for a concurrent read lock on the resource and indicates the values it is interested in receiving. ////////////////////////////////////////////////////////////////////// Add this cross reference once we rebased to the setattr update. For a detailed discussion of all the fields in the 'ldlm_request', 'ldlm_intent', and 'mdt_body' refer to <>, <>, and <>. ////////////////////////////////////////////////////////////////////// .LDLM_ENQUEUE ( intent : getattr ) Request Packet Structure image::ldlm-enqueue-intent-getattr-request.png["LDLM_ENQUEUE (intent : getattr) Request Packet Structure",height=50] ////////////////////////////////////////////////////////////////////// The ldlm-enqueue-intent-getattr-request.png diagram resembles this text art: LDLM_ENQUEUE: --intent:getattr request-------------------------------------- | ptlrpc_body | ldlm_request | ldlm_intent | mdt_body | name | -------------------------------------------------------------- ////////////////////////////////////////////////////////////////////// The ldlm_request structure signals that it has an intent ('lock_flags' = LDLM_FL_HAS_INTENT), The lock descriptor's resource type is 'loc_desc'->'l_resource'->'lr_type'=LDLM_IBITS. The 'ldlm_intent' opcode is for 'getattr' (0x1000). The 'mdt_body' has its 'mbo_valid' field set to 0x28491035fdf, which is these flags: .Flags for 'mbo_valid' field of 'struct mdt_body' [options="header"] |==== | Flag | Meaning | OBD_MD_FLID | FID | OBD_MD_FLATIME | atime attribute | OBD_MD_FLMTIME | mtime attribute | OBD_MD_FLCTIME | ctime attribute | OBD_MD_FLSIZE | size attribute | OBD_MD_FLBLKSZ | block size attribute | OBD_MD_FLMODE | mode attribute | OBD_MD_FLTYPE | type | OBD_MD_FLUID | UID attribute | OBD_MD_FLGID | GID attribute | OBD_MD_FLFLAGS | flags | OBD_MD_FLNLINK | number of links | OBD_MD_FLGENER | generation | OBD_MD_FLRDEV | rdev | OBD_MD_FLEASIZE | extended attributes size | OBD_MD_FLGROUP | group | OBD_MD_FLDIREA | dir extended attributes | OBD_MD_FLMODEASIZE | mode size | OBD_MD_MEA | | OBD_MD_FLACL | ACL | OBD_MD_FLMDSCAPA | |==== In the context of an LDLM_ENQUEUE 'getattr' intent request the flags indicate that Client1 would like to hear back about the flagged attributes. The 'name' buffer is one byte long in this case. That signifies an empty string ('\0'). The resource was identified by FID in this case, but in other circumstances it might be identified by name via a string value in the last buffer. 2 - The LDLM_ENQUEUE reply returns the indicated attribute values to Client1. In addition to the 'ptlrpc_body' (RPC message header), the LDLM_ENQUEUE reply RPC to Client1 has an 'ldlm_reply', an 'mdt_body', and an 'mdt_md' structure. ////////////////////////////////////////////////////////////////////// Add this cross reference once we rebased to the setattr update. For a detailed discussion of the fields in 'ldlm_reply', 'mdt_body', and 'mdt_md' refer to <>, <>, and <>. ////////////////////////////////////////////////////////////////////// .LDLM_ENQUEUE (intent : getattr ) Reply Packet Structure image::ldlm-enqueue-intent-getattr-reply.png["LDLM_ENQUEUE ( intent : getattr ) Reply Packet Structure",height=50] ////////////////////////////////////////////////////////////////////// The ldlm-enqueue-intent-getattr-reply.png diagram resembles this text art: LDLM_ENQUEUE: --intent:getattr reply-------------------------- | ptlrpc_body | ldlm_reply | mdt_body | mdt_md | ------------------------------------------------ ////////////////////////////////////////////////////////////////////// The reply from the MDT grants the requested concurrent read lock on the resource. The 'mdt_body' carries the 'getattr' attribute information that was being requested. The mbo_valid field indicates that it is replying with this set of valid fields (0x8080022f8f): .Flags for 'mbo_valid' field of 'struct mdt_body' [options="header"] |==== | Flag | Meaning | OBD_MD_FLID | FID | OBD_MD_FLATIME | atime attribute | OBD_MD_FLMTIME | mtime attribute | OBD_MD_FLCTIME | ctime attribute | OBD_MD_FLMODE | mode attribute | OBD_MD_FLTYPE | type | OBD_MD_FLUID | UID attribute | OBD_MD_FLGID | GID attribute | OBD_MD_FLFLAGS | flags | OBD_MD_FLNLINK | number of links attribute | OBD_MD_FLEASIZE | extended attributes size | OBD_MD_FLMODEASIZE | | OBD_MD_FLACL | ACL |==== As a bonus the MDT returnes layout information about the file, so that Client1 can get attribute information from the OST(s) responsible for the file's objects (if any). 3 - Client1 asks for a protected read lock on the resource on the OST. The previous RPC provided layout information to Client1 enabling it to query the OSTs (one of them in this case) about the object's attributes. The LDLM_ ENQUEUE indicates the desired (on-OST) resource and that it should be a protected read of type LDLM_EXTENT (11). .LDLM_ENQUEUE Request Packet Structure image::ldlm-enqueue-request.png["LDLM_ENQUEUE Request Packet Structure",height=50] ////////////////////////////////////////////////////////////////////// The ldlm-enqueue-request.png diagram resembles this text art: LDLM_ENQUEUE: --request--------------------- | ptlrpc_body | ldlm_request | ------------------------------ ////////////////////////////////////////////////////////////////////// 4 - The OST invokes a glimps lock callback on Client2. Client2 previously had a lock on the desired resource, and the glimpse induces Client2 to flush its buffers, if needed, and update the OST size and time attributes. The LDLM_GL_CALLBACK asks for a write lock on the entire extent of the resource. .LDLM_GL_CALLBACK Request Packet Structure image::ldlm-gl-callback-request.png["LDLM_GL_CALLBACK Request Packet Structure",height=50] ////////////////////////////////////////////////////////////////////// The ldlm-gl-callback-request.png diagram resembles this text art: LDLM_GL_CALLBACK: --request--------------------- | ptlrpc_body | ldlm_request | ------------------------------ ////////////////////////////////////////////////////////////////////// 5 - Client2 replies with LVB data for the OST. The OST is waiting to hear back from Client2 to update size and time attributes, if needed, due to Client2 chache being flushed to the OST. The glimpse allows the information to return to the OST, and thereby get passed to Client1, without taking the lock from Client2. .LDLM_GL_CALLBACK Reply Packet Structure image::ldlm-gl-callback-reply.png["LDLM_GL_CALLBACK Reply Packet Structure",height=50] ////////////////////////////////////////////////////////////////////// The ldlm-gl-callback-reply.png diagram resembles this text art: LDLM_GL_CALLBACK: --reply------------------ | ptlrpc_body | ost_lvb | ------------------------- ////////////////////////////////////////////////////////////////////// The 'ost_lvb' data from Client2 has atribute data to update the OST. 6 - The OST replies with the updated attribute information. .LDLM_ENQUEUE Intent:LVB Reply Packet Structure image::ldlm-enqueue-intent-lvb-reply.png["LDLM_ENQUEUE Intent:LVB Reply Packet Structure",height=50] ////////////////////////////////////////////////////////////////////// The ldlm-enqueue-intent-lvb-reply.png diagram resembles this text art: LDLM_ENQUEUE: --intent:lvb reply-------------------- | ptlrpc_body | ldlm_reply | ost_lvb | -------------------------------------- ////////////////////////////////////////////////////////////////////// The lock is not granted, but the attribute data has been updated.