Subject: [nfsv4] Parallel open support

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 18 Sep 2006 18:16:55 -0400

Two ways of supporting this have been proposed:

	Maintaining the current open upgrade logic and mandating
incrementing of successive seqids for successively return stateids for
the same file-handle/openowner pair.
	 
	Getting rid of the v4.0 upgrade logic. and therefore getting rid
of successive stateid that would have to be sorted using seqids.

The second seems to me to produce significantly simpler implementations
in dealing with parallel opens.
 
It has been claimed that POSIX somehow requires the v4.0 upgrade logic,
but I don't see this. The current implementations of open
upgrade/downgrade do not conform to the POSIX semantics of releasing all
locks for a given file, no matter what the file descriptor, whenever a
close on any of those file descriptors is done.  This is because when
you do a close() you will either locally drop a reference to file (and
do nothing over the wire) or do an OPEN_DOWNGRADE and so if all these
locks are released, the client has to do it itself. Given that, I don't
see that we have any reason to maintain the upgrade logic.
 
If someone does really need to implement this semantic (and so far
nobody has indicated a real need for this, i.e. there have been no
people complaining about a bug), I think the right thing to do would be
to create an UNLOCK_ALL op which releases all locks on a given file for
a given lockowner (no matter what the openowner), and let anyone who is
interested in having this  semantics issue it whenever appropriate, i.e.
whenever the client has multiple opens for the same file where there are
or might be unreleased byte-range locks. 
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 18 Sep 2006 17:32:45 -0500

> or might be unreleased byte-range locks. 

So, I must be very confused.  Does the second option you present 
remove the ability to upgrade an OPEN (read -> read/write)?  Or does
it say that an upgrade can occur but it doesn't really matter in
what order it is done since if there is a deny requested that the deny
will sort itself out with respect to ordering?

Spencer

---

From: eric kustarz <[email-masked]>
Date: Mon, 18 Sep 2006 17:06:07 -0700

Noveck, Dave wrote:

>     incrementing of successive seqids for successively return stateids
>     for the same file-handle/openowner pair.
>      
> The second seems to me to produce 
> significantly simpler implementations in dealing with parallel opens.

This is in regards to parallel opens on the same file, right?  As 
opposed to parallel opens from the same open owner on different files?

>  
> It has been claimed that POSIX somehow requires the v4.0 upgrade 
> logic, but I don't see this. The current implementations of open 
> upgrade/downgrade do not conform to the POSIX semantics of releasing 
> all locks for a given file, no matter what the file descriptor, 
> whenever a close on any of those file descriptors is done.  This is 
> because when you do a close() you will either locally drop a reference 
> to file (and do nothing over the wire) or do an OPEN_DOWNGRADE and so 
> if all these locks are released, the client has to do it itself. Given 
> that, I don't see that we have any reason to maintain the upgrade logic.

The Solaris client actually does release its locks when close() is 
called (whether or not its doing a downgrade OTW, a close OTW, or 
neither), check out nfs4_lockrelease() and nfs4close_one():
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/fs/nfs/nfs4_vnops.c#nfs4_close

eric

>  
> If someone does really need to implement this semantic (and so 
> far nobody has indicated a real need for this, i.e. there have been 
> no people complaining about a bug), I think the right thing to do 
> would be to create an UNLOCK_ALL op which releases all locks on a 
> given file for a given lockowner (no matter what the openowner), and 
> let anyone who is interested in having this  semantics issue it 
> whenever appropriate, i.e. whenever the client has multiple opens for 
> the same file where there are or might be unreleased byte-range locks. 
>
>------------------------------------------------------------------------
>