Subject: Changes for Open upgrade/downgrade

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 4 Jan 2000 09:53:52 -0800

These are my suggested changes to address the issue of
upgrade/downgrade of an existing open to deal with the
situation that arises when another open by the same 
lockowner is done with different access/deny bits.
When this happens (and also when such opens are closed),
the new access/deny status needs to be changed on the
server or else share reservation requests by other clients
will be granted or denied incorrectly.

One point to note in dealng with this problem is that the
client may not know, when he issues the OPEN, whether the
file which he is opening is the same as the one he has
already opened.  Also, if the server chooses to give
out multiple different handles for the same file (because
of multiple links or for any other reason), the client
may not know even, even after the open whether the two
files in question are in fact the same.

This is all relative to draft-03.

----

Add a new section following section 8.8:

8.x.  Open upgrade and downgrade

     When an OPEN is done to a file and the lockowner for
     which the open is being done already has the file open,
     the result is to upgrade the open file status maintained
     on the server to include the access and deny bits
     specified by the new OPEN as well as those for the
     existing OPEN.  The result is that there is one open
     file, as far as the protocol is concerned, and it 
     includes the union of the access and deny bits for all
     of the OPEN requests done.  Only a single CLOSE will 
     be done to undo the effects of both OPEN's.  Note 
     that the client, when issuing the OPEN, may not know 
     that the same file is in fact being opened.  The above 
     only applies if both OPEN's result in the OPEN'ed object
     being designated by the same filehandle.

     When the server chooses to export multiple filehandles
     corresponding to the same file object, and returns
     different filehandles on two different OPEN's of the
     same file object, it MUST NOT or together the access 
     and deny bits and coalesce the two open files, but 
     instead must maintain separate OPEN's with separate
     stateid's and will require separate CLOSE's to free
     them.

     When multiple open files on the client are merged into
     a single open file object on the server, the close of
     one of the open files may necessitate change of the
     access and deny status of the open file on the server.
     This is because the union of the access and deny bits
     for the remaining open's may be smaller (i.e. a proper
     subset) than previously.  The OPEN_DOWNGRADE operation
     is used to make the necessary change and the client
     should use it to update the server so that share 
     reservation requests by other clients are handled 
     properly.

Add to section 14.2.17 (OPEN) under DESCRIPTION the following
new paragraph at the end:

     When an OPEN is done and the specified lockowner already
     has the resulting filehandle open, the result is to 
     or together the new share and deny status together with
     the existing status.  In this case, only a single CLOSE
     need be done, even though multiple OPEN's were done.

Add the following new section:

14.2.xx.  Operation yy: OPEN_DOWNGRADE - Reduce open file access

  SYNOPSIS

     (cfh), stateid, seqid, access, deny -> stateid

  ARGUMENT

     struct OPEN_DOWNGRADE4args {
     		/* CURRENT_FH: opened file */
     		stateid4	stateid;
		seqid4	seqid;
		uint32_t	share_access;
		uint32_t	share_deny;
     };

[[Note: all of the OPEN4_SHARE_* constants for share_{access,deny}
  are (not unreasonably) under OPEN.  If they are used in more than
  one op, they may have to be pulled forward somehow and genericized.]]

  RESULT

     struct OPEN_DOWNGRADE4resok {
		stateid4	stateid;
     };

     union OPEN_DOWNGRADE4res switch(nfsstat4 status) {
	case NFS4_OK:
		OPEN_DOWNGRADE4resok	resok4;
	default:
		void;
     };

  DESCRIPTION

     This operation is used to adjust the access and deny bits for
     a given open.  This is necessary when a given lockowner opens
     the same file multiple times with different access and deny
     flags.  In this situation, a close of one of the open's may
     change the appropriate access and deny flags to remove bits
     associated with open's no longer in effect.

     The access and deny bits speicifed in this operation replace
     the current ones for the specified open file.  If either
     the access or the deny mode specified includes bits not
     in effect for the open, the error NFS4ERR_INVAL should be
     returned.  Since access and deny bits are subsets of those
     already granted, it is is not possible for this request to
     denied because of conflicting share reserveations.

     On success, the current filehandle retains its value.
    
  ERRORS

     NFS4ERR_BADHANDLE
     NFS4ERR_BAD_SEQID
     NFS4ERR_BAD_STATEID
     NFS4ERR_EXPIRED
     NFS4ERR_FHEXPIRED
     NFS4ERR_INVAL
     NFS4ERR_MOVED
     NFS4ERR_NOFILEHANDLE
     NFS4ERR_OLD_STATEID
     NFS4ERR_RESOURCE
     NFS4ERR_SERVERFAULT
     NFS4ERR_STALE
     NFS4ERR_STALE_STATEID

Also, corresponding changes in section 17.

---

From: Mike Kupfer <[email-masked]>
Date: Thu, 06 Jan 2000 11:38:20 -0800

This looks like a good (and necessary) change to me.

I have one suggestion about wording.  You suggested the following
text:

I would make that

     When multiple open files on the client are merged into a single
     open file object on the server, the close of one of the open
     files (on the client) may necessitate change of the access and
           ^^^^^^^^^^^^^^^
     deny status of the open file on the server.

mike