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

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 7 Aug 2003 13:33:11 -0700

The other thing you could do is when you get to (7), you
can look to see if your are doing an open for write when
you have a read delegation.  At that point, you know the
delegation will be recalled, so you can choose to return
it in advance.  In that case, you can issue the DLGCUR 
open and the dlgreturn as a single COMPOUND, although
only the open is necessary to avoid the seqid issue.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Thursday, August 07, 2003 2:16 PM
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