From 56cde16d1bdc198cf419a322e25a39c11b47a5fd Mon Sep 17 00:00:00 2001
From: adilger <adilger>
Date: Thu, 19 Sep 2002 22:33:19 +0000
Subject: [PATCH] Add a comment on why we don't return a lock for some
 operations.

---
 lustre/mds/handler.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/lustre/mds/handler.c b/lustre/mds/handler.c
index 3fef706..5b3740c 100644
--- a/lustre/mds/handler.c
+++ b/lustre/mds/handler.c
@@ -1275,11 +1275,15 @@ static int ldlm_intent_policy(struct ldlm_lock *lock, void *req_cookie,
                         LBUG();
                 }
 
-                /* XXX Why is this logical to abort lock acq 
-                   in these cases? .... PJB
-                */
-                if (it->opc & (IT_UNLINK | IT_RMDIR | 
-                               IT_LINK2 | IT_LINK | 
+                /* We don't bother returning a lock to the client for a file
+                 * or directory we are removing.
+                 *
+                 * As for link and rename, there is no reason for the client
+                 * to get a lock on the target at this point.  If they are
+                 * going to modify the file/directory later they will get a
+                 * lock at that time.
+                 */
+                if (it->opc & (IT_UNLINK | IT_RMDIR | IT_LINK | IT_LINK2 |
                                IT_RENAME | IT_RENAME2))
                         RETURN(ELDLM_LOCK_ABORTED);
 
-- 
1.8.3.1