Whamcloud - gitweb
LUDOC-276 protocol: Document RPCs for setattr
[doc/protocol.git] / ldlm_resource_desc.txt
diff --git a/ldlm_resource_desc.txt b/ldlm_resource_desc.txt
new file mode 100644 (file)
index 0000000..c50781f
--- /dev/null
@@ -0,0 +1,42 @@
+LDLM Resource Descriptor
+^^^^^^^^^^^^^^^^^^^^^^^^
+[[struct-ldlm-resource-desc]]
+
+The resource descriptor identifies the individual resource that is
+being locked, along with what sort of thing it is.
+
+----
+struct ldlm_resource_desc {
+        ldlm_type_t lr_type;
+        __u32 lr_padding;       /* also fix lustre_swab_ldlm_resource_desc */
+        struct ldlm_res_id lr_name;
+};
+----
+
+The 'lr_type' field identifies one of the four types of lock that
+might be placed on a resource. A "plain" lock type just locks a
+particular resource. An "extent" lock type only locks a contiguous
+sequence of byte offsets within a regular file. An "flock" lock type
+represents an application layer advisory lock from the 'flock()'
+system call. While Lustre manages "flock" types locks on behalf of the
+application, they do not affect Lustre operation.  An "ibits" lock
+type allows fine grained locking of different parts of a single
+resource. A single lock request or cancellation may operate on one or
+more lock bits, or individual lock bits may be granted on the same
+resource separately.  See also <<ldlm-wire-policy-data-t>>.  A lock
+descriptor may also have no type at all, in which case the 'lr_type'
+field is 0, meaning "no lock".
+
+The 'lr_name' field identifies (by name) the resource(s) that are the
+objects of the locking operation. See the discussion of
+<<struct-ldlm-res-id>>.
+
+----
+typedef enum {
+        LDLM_PLAIN     = 10,
+        LDLM_EXTENT    = 11,
+        LDLM_FLOCK     = 12,
+        LDLM_IBITS     = 13,
+} ldlm_type_t;
+----
+