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

From: Mike Eisler <[email-masked]>
Date: Fri, 3 Nov 2000 14:17:13 -0800 (PST)

"Carl Beame" <[email-masked]> writes:

> > 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.
> 
> 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?

As the spec is currently written, yes. 

> 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

but you could restablish them on the new open correct?

> 
> 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.

You would lock them on the second file handle. 

> 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

Yes.

> handle this by using multiple opens and multiple closes?

Here is the situation folks were concerned with.  Let's
suppose the client issues two OPENs on the same file and
nfs_lockowner, each with same initial sequence #.
Distinguishing the OPENs, especially if they have same
creds, same args, is hard.  There was also the worry abount
the Byzantine Router re-send an OPEN, though I think the
open confirmation stuff that was added after the
upgrade/downgrade discussion mitigates this.

You could certainly take the existing .x file, write a new
internet-draft to match it (though I think that 64 bit
stateids will be too small) to a model that assigns a
unique sequence per open/nfs_lockowner pair. Open
confirmation would be needed to distinguish OPEN with the
same signature. Such an approach will also consume more
server memory.

But that's not the protocol we have a pending proposed
standard for.

So, do we want to kill the current pending proposed standard?
	-mre