Subject: downgrade/upgrade (was Re: Spec-related discussions at the Bake-off)

From: Mike Eisler <[email-masked]>
Date: Fri, 3 Nov 2000 03:28:26 -0800 (PST)

"David Robinson" <[email-masked]> writes:

> I don't recall what the motivation for an upgrade/downgrade OPEN was.

Just scanned the archive, looking for "downgrade" in a case insensitive
search. BTW, I was not a participant in the discussion, so this is all
based on reading the archive and not recollection of my thoughts at the
time.

The deal is this:

UNIX process opens file "A" with mode READ and
the nfs v4 file system issues the OPEN with mode READ, and deny NONE.

The same process now opens "A" again, but this time with mode WRITE.
NFSv4 has no notion of a unique file descriptor. Given that the
nfs_lockowner is the same, and the file is the same, the only way the server
can handle this is to treat the operation as an upgrade. So the nfsv4
file system sends an OPEN with mode READ/WRITE and deny NONE.

I gathered from the discussion that the Windows API would not allow the
same process to open the file with two different modes, but in any
case, this is immaterial, since UNIX does.

When the process closes one of the file descriptors on "A", the NFSv4
file system needs to downgrade the SHARE to either READ or WRITE on the
server. It cannot issue a CLOSE, because this removes all the SHARE
state, so would leave a window for another client to OPEN the file with
a DENY=~NONE, and so prevent the client from doing another OPEN to
re-open the file. So an OPEN_DOWNGRADE operation is needed to deal with
this.

> I don't believe that any existing APIs that handle shares has this
> capability so I question why it shouldn't just be done with a CLOSE
> followed by an OPEN, if it is ever needed.

See the above.

Dave Noveck writes:

> > 15) NT server issues with OPEN upgrade
> > 
> > The Hummingbird people have come up with an issue regarding the open 
upgrade-downgrade model that is currently in
> > the spec. There is no easy method whereby an NT server might implement a 
downgrade request in general. NT does
> > not provide the requisite semantics. 

The lack of an NT API for atomic downgrade of SHAREs seems to be the
real pain here. It means that some interactions among NFSv4 clients to
the NT servers, local processes on the NT server, and CIFS clients to
the NT server won't work all the time, due to windows when the NT NFSv4
server needs to temporarily close a file.

> > It might implement this by handling the open upgrade by doing a second open 
and then closing one of its open's when a
> > downgrade is done. There are some problems with this. As the spec stands, 
the client is not constrained in precisely
> > what downgrades it would do, making it possible for it to make requests, 
that cannot be handled by the server closing
> > one of its opens. Even if this could be resolved, there remains an issue

I don't understand. The spec is very explicit in that OPEN_DOWNGRADE
must not add bits not present in the previous OPEN for the nfs_lockowner/file
pair. 

> > with byte-range locks. The NT server has no
> > way of knowing which of his opens to assign the locks to. He might assign 
them to an open which needs to be closed
> > to satisfy a subsequent downgrade. 

For a given nfs_lockowner/file_handle pair there is just one
oustanding OPEN. Thus the byte range locks would be moved to the second open,
which then becomes the only open after the previous open is closed.

	-mre

---

From: Carl Beame <[email-masked]>
Date: 03 Nov 2000 17:04:14 +0000

> case, this is immaterial, since UNIX does.

As Dave stated NT can open the same file many times as long as the
sharing/access modes don't conflict. This is actually the same as in
Unix as normal Unix might be DENY_NONE.

> re-open the file. So an OPEN_DOWNGRADE operation is needed to deal

You say it cannot issue a close, because close closes all opens to the
same file, because the stateid returned by open for the same
file/lockowner is the same. What I am saying is make it different, and
it all works. Are you saying that your CAN'T have a different stateid
for each opening of the same file/lockowner?

> > followed by an OPEN, if it is ever needed.

We have two possible solutions to implement downgrade. 

1) Close the currently open file on the open upgrade and reopen the
file. 

	Problem: All Locks would be lost

2) Open a second file handle with the new sharing mode and on the open
downgrade close the corresponding file handle.

	Problem: While both are open and a lock request comes in, which file
do we lock? We may lock the file handle which gets closed in the
downgrade and loss the lock which should remain.

It seems to me that the Unix client is converting a "second" open to
an open upgrade and then converting the "first" close to an open
downgrade and then the last close to a CLOSE. Why not let the server
handle this by using multiple opens and multiple closes?

- Carl

---

From: David Robinson <[email-masked]>
Date: Fri, 03 Nov 2000 07:42:02 -0800

> re-open the file. So an OPEN_DOWNGRADE operation is needed to deal with

As the Unix process that opens the file a second time creates a second
file descriptor, it can be argued that this is a different open and the
client should not collapse them into a single access.  To solve this
problem a client can create a new nfs_owner even though both OPENs are
within the same process.  This will cause some extra work as many Unix
OSes may merge the record locking state of all descriptors to the same
file within the same process. But for other accesses this should not
create any problems having the same process with multiple owners.

	-David