Subject: [nfsv4] Question on Delegation CB_RECALL and DELEGRETURN

From: Arnab Bakshi <[email-masked]>
Date: Fri, 31 May 2013 15:41:42 +0530

Hi,

   Was going through the RFC5661 and particularly focusing on the
Delegation part. I have couple of questions which I would like to put here:

Scenario:     Suppose a NFS client (client A) has been granted Read/Write
delegation by a NFS server for a particular file. Now after sometime
another client (client B) requests conflicting Delegation on the same file.
Ideally in this case the server will send a CB_RECALL to client-A to get
back the delegation. Suppose the client behaviour is that it sends a CB_OK
response and does actual IO to flush its state to the server.

Question1:     Client-A keeps sending IO which say is suppose very big and
time consuming therefore delaying DELEGRETURN. What steps does the server
take? Will it try to revoke the delegation forcefully after some elapsed
time and how?.

Question2:     Client-A sends IO for sometime and then somehow becomes idle
and doesn't send the DELEGRETURN. What does the server do in this case,
will it revoke and how?

I know this is a negative scenario but would be helpful to know what should
be the behavior from the server side.

Thanks in advance...

Regards
Arnab

---

From: Rick Macklem <[email-masked]>
Date: Fri, 31 May 2013 19:33:58 -0400 (EDT)

Arnab Bakshi wrote:
> another client (client B) requests conflicting Delegation on the same
> file. Ideally in this case the server will send a CB_RECALL to
> client-A to get back the delegation. Suppose the client behaviour is
> that it sends a CB_OK response and does actual IO to flush its state
> to the server.
> 
> 
> time consuming therefore delaying DELEGRETURN. What steps does the
> server take? Will it try to revoke the delegation forcefully after
> some elapsed time and how?.
> 
Well, I'm not sure there is a well defined correct answer for these
questions, but here is what the FreeBSD server does.

Since Client-A keeps sending IO requests, it is not crashed/network
partitioned and, as such, the FreeBSD server will return NFS4ERR_DELAY
to conflicting Open requests until Client-A does DELEGRETURN. (A client
that never sends a DELEGRETURN is broken and since there are only 3-4
clients out there, I don't believe any of them are broken this way?)

> 
> Question2: Client-A sends IO for sometime and then somehow becomes
> idle and doesn't send the DELEGRETURN. What does the server do in this
> case, will it revoke and how?
> 
If Client-A has crashed or is network partitioned, the lease will expire
and after that happens the FreeBSD throws away all state (including all
delegations) for that client and returns NFS4ERR_EXPIRED for the clientid
and all associated stateids. After the delegation has expired, the conflicting
Open succeeds. (The conflicting Open gets NFS4ERR_DELAY for all attempts
until lease expiry.)

I haven't looked at WANT_DELEGATION yet, so I am not sure if I will handle
that like a conflicting Open or simply return something like the extended
delegate none with resource as the reason for not issuing the delegation.

rick

> 
> I know this is a negative scenario but would be helpful to know what
> should be the behavior from the server side.
> 
> 
> Thanks in advance...
> 
> 
> Regards
> Arnab
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4