Subject: [nfsv4] re: old stateid

From: [email-masked]
Date: Thu, 11 Sep 2003 20:05:13 -0400 (EDT)

> 1. Client opens file for read.
> 
> 2. Another process opens the (same) file for write (using same open owner 
> as #1).

Although I suppose it is up to the client writer, why would a different
process use the same open_owner?

> 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?)

> 4. Process from step 1 issues a read to the server. This will be done with 
> the stateid from step 1, while the server thinks the correct stateid comes 
> from step 2. The server will return an error (STALE_STATEID).

Wouldn't this be NFSERR_OLDSTATEID, not NFSERR_STALESTATEID?

> There seems to be no graceful way to recover from this condition where the 
> server and client stateids are hopelessly out of sync. How does a client 
> recover without producing errors to the application?

Sounds to me like the client has to be very careful to not let it happen.

Wow, for once I get to help answer one of these instead of ask them. But
then, maybe my answer is way off the mark, anyhow, rick

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

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 11 Sep 2003 19:31:24 -0500

> 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.

Spencer