--- /dev/null
+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 <<fstat-rpcs>>.
+
+.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
+<<struct-ldlm-request>>, <<struct-ldlm-intent>>, and
+<<struct-mdt-body>>.
+//////////////////////////////////////////////////////////////////////
+
+.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
+<<struct-ldlm-reply>>, <<struct-mdt-body>>, and <<struct-mdt-md>>.
+//////////////////////////////////////////////////////////////////////
+
+.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.
git://git.whamcloud.com / doc / protocol.git / blobdiff