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

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 6 Nov 2000 11:30:36 -0800

David Robinson wrote:
> Mike Eisler wrote:
> > 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.

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

It could be so argued, if someone was prepared to do it.

Are you saying that the spec should be modified so that clients are 
required to do that?  

> To solve this
> problem a client can create a new nfs_owner even though both OPENs are
> within the same process.

It is the server which has the problem dealing with this.

The client is not going to create new lock_owners unless the spec tells
him that (and when) he must.  

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

I believe there are situations in which this would not work, at least
if work is defined as having a UNIX client and server work together and
get the same results as wuld be gotten with a local file system.  There
are lots of cases in which the flock behavior (and mandatory locking as
well depends) on making a distinction based on whether the owner of
the existing lock and the process dong an operation are "the same".  
If the client defines two owners within the same process (eseentially
willy-nilly), this isn't going to work right.

Besides, this has the same problems as changing stateid to be per-open-
file-instance.  How is the client implementation to know for which
open file (and thus for which lockowner) a given lock operation is
for, if this information is not available across the VOP interface,
and I think it isn't in many UNIX'es?

---

From: David Robinson <[email-masked]>
Date: Mon, 06 Nov 2000 20:00:43 -0800

> Are you saying that the spec should be modified so that clients are

I have not spent the time to really understand how Windows works on
this,
but it appears that there can be a compromise that works in most
interesting
cases.  Since Unix doesn't really have a SHARE interface, the
interpretation
of what it should generate can be adapted as needed. On the Windows
side,
it has real APIs that expect certain behavior so the protocol should
bend towards it within reason. So I would look to defining the server
semantics strictly and putting the burden more on the client in this
case.
So I would argue that the burden is on the Unix side to find an
acceptable
method to accomedate Windows servers.

> him that (and when) he must.

I realize that it is the servers problem, I am saying we should consider
disallowing the client from doing that or at least forcing them to
handle the server saying, "sorry, unable".

> and I think it isn't in many UNIX'es?

True, under most VFS interfaces there is little distinction between a
file
opened once or N times.

	-David