--- /dev/null
+MDT Body
+^^^^^^^^
+[[struct-mdt-body]]
+
+An 'mdt_body' structure conveys information about the metadata for a
+resource.
+
+----
+struct mdt_body {
+ struct lu_fid mbo_fid1; /* OBD_MD_FLID */
+ struct lu_fid mbo_fid2; /* OBD_MD_FLID */
+ struct lustre_handle mbo_handle;
+ __u64 mbo_valid;
+ __u64 mbo_size; /* OBD_MD_FLSIZE */
+ __s64 mbo_mtime; /* OBD_MD_FLATIME */
+ __s64 mbo_atime; /* OBD_MD_FLMTIME */
+ __s64 mbo_ctime; /* OBD_MD_FLCTIME */
+ __u64 mbo_blocks; /* OBD_MD_FLBLOCKS */
+ __u64 mbo_ioepoch;
+ __u64 mbo_t_state; /* OBD_MD_TSTATE */
+ __u32 mbo_fsuid;
+ __u32 mbo_fsgid;
+ __u32 mbo_capability;
+ __u32 mbo_mode; /* OBD_MD_FLMODE */
+ __u32 mbo_uid; /* OBD_MD_FLUID */
+ __u32 mbo_gid; /* OBD_MD_FLGID */
+ __u32 mbo_flags; /* OBD_MD_FLFLAGS */
+ __u32 mbo_rdev; /* OBD_MD_FLRDEV */
+ __u32 mbo_nlink; /* OBD_MD_FLNLINK */
+ __u32 mbo_unused2;
+ __u32 mbo_suppgid;
+ __u32 mbo_eadatasize; /* OBD_MD_FLEASIZE */
+ __u32 mbo_aclsize; /* OBD_MD_FLACL */
+ __u32 mbo_max_mdsize; /* OBD_MD_FLMODEASIZE */
+ __u32 mbo_max_cookiesize; /* OBD_MD_FLMODEASIZE */
+ __u32 mbo_uid_h;
+ __u32 mbo_gid_h;
+ __u32 mbo_padding_5;
+ __u64 mbo_padding_6;
+ __u64 mbo_padding_7;
+ __u64 mbo_padding_8;
+ __u64 mbo_padding_9;
+ __u64 mbo_padding_10;
+}; /* 216 */
+----
+
+For an operation that involves two resources both the 'mbo_fid1' and
+'mbo_fid2' fields will be filled in. If the 'mdt_body' is part of an
+RPC affecting or involving only a single resource then 'mbo_fid1' will
+designate that resource and 'mbo_fid2' will be cleared (see
+<<file-id>>).
+
+The 'mbo_handle' field indicates the identity of an open file related
+to the operation, if any. If there is no lock then it is just 0.
+
+The 'mbo_valid' field identifies which of the remaining fields are
+actually in force. The flags in 'mbo_valid' are:
+
+----
+#define OBD_MD_FLID (0x00000001ULL)
+#define OBD_MD_FLATIME (0x00000002ULL)
+#define OBD_MD_FLMTIME (0x00000004ULL)
+#define OBD_MD_FLCTIME (0x00000008ULL)
+#define OBD_MD_FLSIZE (0x00000010ULL)
+#define OBD_MD_FLBLOCKS (0x00000020ULL)
+#define OBD_MD_FLMODE (0x00000080ULL)
+#define OBD_MD_FLUID (0x00000200ULL)
+#define OBD_MD_FLGID (0x00000400ULL)
+#define OBD_MD_FLFLAGS (0x00000800ULL)
+#define OBD_MD_FLNLINK (0x00002000ULL)
+#define OBD_MD_FLRDEV (0x00010000ULL)
+#define OBD_MD_FLEASIZE (0x00020000ULL)
+#define OBD_MD_FLMODEASIZE (0x80000000ULL)
+#define OBD_MD_TSTATE (0x0000000800000000ULL)
+#define OBD_MD_FLACL (0x0000008000000000ULL)
+----
+
+Which flag is associated with which field is indicated in the comments
+beside the fields in the struct definition above. The fields without
+corresponding flags in the 'mbo_valid' field should be considered
+valid, though I'm not sure how much they actually get used.
+
+Many of the fields have names and meanings that correspond directly to
+those in 'struct mdt_rec_setattr' (ex. 'atime', 'size', 'mode',
+etc). Mainly these are the conventional metadata attributes, and
+should be self-explanatory. The ones that are a little less obvious are
+discussed here.
+
+The 'mbo_ioepoch' field is no longer in use.
+
+The 'mbo_t_state' field indicates if there is a "transient state", as
+when an HSM "restore" is in operation.
+
+The 'mbo_rdev' field holds the special device number for a block or
+character device associated with the resource, if there is one. It will
+be 0 for a regular file.
+
+The 'mbo_nlink' field gives the number of hard links to the resource.
+
+The 'mbo_eadatasize' field gives the size of the extended attributes,
+which hold such information as the resource's layout.
+
+The 'mbo_aclsize' field supports POSIX access control lists (ACLs).
+
+The 'mbo_max_mdsize' field
+
+The 'mbo_max_cookiesize' field is unused.
+
git://git.whamcloud.com / doc / protocol.git / blobdiff