Subject: [nfsv4] The close operation, and its effect on locks.

From: Trond Myklebust <[email-masked]>
Date: Thu, 14 Sep 2006 16:55:56 -0400

The close() function shall deallocate the file descriptor
        indicated by fildes. To deallocate means to make the file
        descriptor available for return by subsequent calls to open() or
        other functions that allocate file descriptors. All outstanding
        record locks owned by the process on the file associated with
        the file descriptor shall be removed (that is, unlocked).

http://www.opengroup.org/onlinepubs/009695399/functions/close.html

Note the language: "all .... locks ... on the file" is always
interpreted to mean _independent_ of which actual file descriptor that
set them.

Cheers,
  Trond

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 14 Sep 2006 18:25:35 -0400

But how does the upgrade logic in the protocol provide or help
in implementation of this semantic?

Suppose I open A for read and get back stateid S (seq=0) and 
that is filedes X. 

So now I open (as the same owner) B for write and it turns out
that B is a hard link to A and so I get back stateid S(seq=1)
and S now refers to a file opened for read-write and we now
assign filedes Y to that.

So now I get some locks on each of the two filedeses.

Now I close Y.  What does the client do?  He certainly can't
do a CLOSE of stateid S since that would close filedes X.
I assume he does an OPEN_DOWNGRADE.  If any of those locks
gets freed as the quoted text would require, it because
the client does it itself, and he does it himself, he could
just as well do it if he had two stateids S and T for the
two open files.  

So it doesn't seem to me that open-upgrade helps in 
implementing these semantics.  If you really wanted to
implement them, I think the best path would be to get rid
of the upgrade path and give us an operation that said
"free all locks for this fh associated with this openowner"
for those that wanted to implment that sort of semantics.

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]] 
Sent: Thursday, September 14, 2006 4:56 PM
To: Noveck, Dave
Cc: [email-masked]
Subject: The close operation, and its effect on locks.

Cheers,
  Trond