Subject: Re: [nfsv4] Question on Delegation CB_RECALL and DELEGRETURN

From: Arnab Bakshi <[email-masked]>
Date: Sat, 1 Jun 2013 12:01:28 +0530

Thanks Rick..my comments inline...

On Jun 1, 2013 5:03 AM, "Rick Macklem" <[email-masked]> wrote:
>
> Arnab Bakshi wrote:
> > 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?.
> >
> 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?)
>
The implementation makes sense. To put it more specifically if client
closes the transport connection before it sends DELEGRETURN then hopefully
server clears the state for the client-id and the associated state-id,is it
so...? The clients available are surely not broken but I am interested more
from protocol definition perpective. ?.
> >
> > 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