Subject: RE: [nfsv4] Delegation recall with truncate set

From: "Khan, Saadia" <[email-masked]>
Date: Thu, 7 Aug 2003 12:21:18 -0700

However, this scenario applies only when the conflicting request is
coming from the same client. If its coming from a different client, the
server doesn't have to return DELAY.

What do you do if the conflicting request is coming over nfsv2/3?

Saadia

> -----Original Message-----
> From: Spencer Shepler [mailto:[email-masked]] 
> Sent: Thursday, August 07, 2003 11:16 AM
> To: [email-masked]
> Subject: Re: [nfsv4] Delegation recall with truncate set
> 
> 
> On Tue, Noveck, Dave wrote:
> > I don't remember all the details but my understanding
> > was that when we didn't return DELAY, we could get into
> > a situation with the Solaris client in which the recall 
> > callback was not processed and that arranging to return 
> > DELAY solved that.  That's what I was referring to when
> > I said some clients "depend on" the DELAY response.
> 
> Okay.  Thanks for reminding me of what we discussed during 
> Connectathon.  I knew I should have written it down.  With 
> some help to remember the scenario encountered at 
> Connectathon, this is the case where the server returning 
> DELAY can help:
> 
> 	client				server
> 	------				------
> 	<assume same openowner for all ops>
> 
> (1) OPEN(ACCESS_READ) ->
> (2) 				<-	OPEN is okay; provides 
> READ delegation
> (3) CLOSE of OPEN in (1) ->
> (4)				<-	CLOSE is okay
> (5) local open for read
> (6) local open for write
> (7) OPEN(ACCESS_WRITE) ->
> (8)				<-	CB_RECALL of delegation from (2)
> (9) OPEN(ACCESS_READ) ***
> 
> 
> *** The client is attempting to OPEN the file as a result of the
>     delegation recall processing (ensuring all open state is at the
>     server)
> 
> For the client to do the OPEN in (9) is must have the "next" 
> sequence id and it can not obtain it since the response to 
> the OPEN in (7) has not been received. So the client was 
> serialized on access to the sequence id for the openowner and 
> was waiting for the response from (7); the client was hung.
> 
> When the server returns DELAY to the OPEN in (7), then the 
> client will be able to push the OPEN for ACCESS_READ to the 
> server, return the delegation and then resend the OPEN for 
> ACCESS_WRITE.
> 
> I suppose the alternative is the client could have sent an 
> OPEN for both ACCESS_READ and ACCESS_WRITE but it seemed 
> safer to have the server return DELAY.
> 
> Note that our server current employs a heuristic to wait a 
> short amount of time after sending the delegation recall.  It 
> the delegation is not returned, then the DELAY response is 
> sent to the original operation that caused the conflict.  
> This works in a few cases to overcome additional requests.
> 
> Given this particular scenario, it seems best to have the 
> server return DELAY to the conflicting operation (possibly 
> after a very short wait).
> 
> I have also changed my opinion about the server's use of 
> CB_RECALL with truncate == TRUE.  In most cases, the scenario 
> of the client not retransmitting the request that caused the 
> CB_RECALL to occur, seems like an edge case and it is more 
> desirable to avoid the unnecessary transmit of file data when 
> it is likely to be discarded once the delegation is returned.
> 
> 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: Thu, 7 Aug 2003 14:39:01 -0500

> server doesn't have to return DELAY.

Yes. This scenario is very specific because of the sequence id
serialization issue.

> What do you do if the conflicting request is coming over nfsv2/3?

Currently, for NFSv2, the conflicting/pending request is dropped; for
NFSv3, the NFS4ERR_JUKEBOX error is returned.

Spencer