Subject: [nfsv4] server's response to OPEN on conflict with delegation

From: Spencer Shepler <[email-masked]>
Date: Wed, 12 Mar 2003 10:57:44 -0600

During Connectathon testing last week we bumped into a situation where
a server providing delegations was waiting to respond to an OPEN
request until the delegation was returned for the file.  The specific
situation seemed to be a client holding a read delegation had sent an
OPEN for write to the server hence the conflict and the request for
DELEGRETURN.  The client was waiting for the response to the OPEN
before doing the DELEGRETURN.  At the time, it seemed like the client
should go ahead and do the DELEGRETURN without waiting for the OPEN
response.  For that particular situation that looked to be appropriate.

After thinking about this some more, I believe that it may not be
possible for the client to do a DELEGRETURN before receiving the
response to the OPEN.  The particular case I am thinking of is this:

- Client has file open for read and holds a read delegation.
- There have been subsequent opens for read that have not been sent to
  the server under the auspices of the read delegation
- Client then OPENs the file for read/write.  This over the wire
  request can occur if the file is hard linked and being opened under
  both names.
- The server determines the conflict with the read delegation and asks
  the client to DELEGRETURN.
- To process the DELEGRETURN, the client must first OPEN(CLAIM_DELEGATE_CUR)
  for each of the opens done under the delegation.

Assume that all OPENs are done for the same open_owner.  If this is
the case, they must be serialized with respect to the open_seqid for
the open_owner.  Therefore, the server must not delay response to the
conflicting OPEN by too much so as not to delay the client's response.

In the case of conflicting OPENs, the Solaris server will delay ever
so slightly on the OPEN to see if the delegation will be returned but
will then respond with NFS4ERR_DELAY.

Just wanted to bring this up for general implementation discussion.

-- 
Spencer

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4