Subject: [nfsv4] re: re: old stateid problem

From: [email-masked]
Date: Fri, 12 Sep 2003 11:03:19 -0400 (EDT)

>> > 3. Server gets and processes the request (#2), but client never gets reply 
>> > (RPC timeout, N/W condition, impatient user hits ^c with an interruptible 
>> > mount).
>> 
>> I think a client has to retry an RPC with a seqid# in it until it gets the
>> reply and updates the client state. (The only exception might be if it
>> will never use that open_owner again, so it doesn't care about the seqid#
>> any more, which could only be a Close?)
>
>Which the client should do to release the state at the server.
>Obviously, if the client has other state that it is renewing, it will
>leave this open_stateid dangling at the server and consuming resources.

Yes. (The only alternative would be a SetClientID/SetClientIDConfirm.
Sounds pretty extreme, but if the client used a different clientid for
each process group, it might be useful?)
I was typing quickly before I headed home and was thinking of the
following while I typed it:

Specifically, for an interruptible mount, if the process is being
terminated by a signal (such as <ctrl>C), it could terminate, leaving
the cleanup for some ancilliary kernel process/thread. I think the
cleanup would have to include a LockU (if there is an outstanding lock
or the RPC being interrupted included a Lock Op), DelegReturn of any
delegations and Closes, for all Opens now being closed off. (ie no
other process still having the open) If another process still has the
same open, the locks on the LockOwner would need a LockU and the outstanding
RPC would have to be completed, if it is one of (Open, Openconfirm,
OpenDowngrade, Close). Sound about right? (It is times like these
that make me happy I'm not a client writer:-)

Oh, and I/O Ops on a stateid have to be delayed while any Op that can
change the stateid is outstanding. Those could interrupt, so long as the
underlying Op that changes the stateid still gets done, I think?

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 15 Sep 2003 20:52:43 -0500

> that make me happy I'm not a client writer:-)

This is correct.  Eric's Connectathon presentation provides additional
information.

Spencer