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

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 12 Mar 2003 10:10:25 -0800

Good point.  There are cases on the client whose possible
existence forces the server to cut short the conflicting 
request, even if the server has adequate resources to keep 
the request around indefinitely.  Do you know of other 
cases besides this issue with deadlock resulting from
contention for the openowner sequence? 

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 11:58 AM
To: [email-masked]
Subject: [nfsv4] server's response to OPEN on conflict with delegation

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
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

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

> contention for the openowner sequence? 

I don't recall anything at this time but will post if I do recall
other instances.

I can't remember if I have mentioned this in the past but in the
callback path there is a race between a server's CB_GETATTR or
CB_RECALL and the client's doing a DELEGRETURN.  The scenario simply
is that the client initiates a DELEGRETURN on its own and the server
does a CB_GETATTR at the same time.  The DELEGRETURN is serviced and
the client receives the response just before it receives the
CB_GETATTR.  In this case, the client will respond with
NFS4ERR_BADHANDLE to the CB_GETATTR (as well as CB_RECALL).  The
server should take care that this is not a fatal error but potentially
a timing issue.  Of course, if the server, upon receipt of the
NFS4ERR_BADHANDLE, still shows the client holding the delegation, it
has the right to revoke the delegation.

Spencer