Subject: Re: [nfsv4] Out of sync stateid scenario that looks difficult to resolve

From: Carl Burnett <[email-masked]>
Date: Fri, 12 Sep 2003 09:24:08 -0500

Ok Spencer, I think I understand the general approach. I don't really like 
it, but I get it. But one thing you said below does seem a bit puzzling.

"Spencer wrote: In this example, if the
application has exited and the file closed, the client would
presumably send a OPEN_DOWNGRADE()."

If it was a regular OPEN that went to the server, can you really turn 
around the reissue the request using a different operation with the old 
state id that was used with the OPEN? Seems like a smart server would 
realize that's not really a replay and flag it as an error. It seems like the client would have to resend the exact request that did 
not get a reply, and then CLOSE the file. And if the op happens to be a create, the side effects are a bit ugly. The 
client certainly can't turn around and delete the file. You potentially 
end up with an "orphaned file" that the admin or user eventually must 
clean up."

Carl Burnett
AIX Kernel Architecture - Network File System
(512) 838-8498, TL 678-8498
(please reply to [email-masked])

Spencer Shepler <[email-masked]>
Sent by: [email-masked]
09/11/2003 06:28 PM
Please respond to spencer.shepler

        To:     [email-masked]
        cc: 
        Subject:        Re: [nfsv4] Out of sync stateid scenario that looks difficult to resolve

.
.
.

No. The stateid returned after the first OPEN is no longer valid
because the second has been processed by the server.

It is the responsibility of the client to resend the OPEN request to
ensure that the client and server do not become out-of-sync.

In the case of an interrupted request (assuming the application is
interrupted and will exit), the client should have an alternative
agent that resends (not RPC retransmit since that is not "allowed")
the OPEN request.  If the server had already processed it, it will
return the previous results per the matching seqid.  If it had not
been processed, it will be the second time.  In either case, the
client and server are now at a known state.  In this example, if the
application has exited and the file closed, the client would
presumably send a OPEN_DOWNGRADE().

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

---

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

> end up with an "orphaned file" that the admin or user eventually must 

So the exact sequence I was thinking of is this:

OPEN() ->
OPEN(upgrade1) -> [interrupted]
<application closes the OPEN(upgrade) file descriptor>
OPEN(upgrade2) -> [operation resent as in "upgrade1" request]
OPEN_DOWNGRADE() -> [remove effects of OPEN(upgrade)]
...
eventual CLOSE() ->

You are correct that the client must resend the operation exactly as
it was previously sent (stateid and sequence id).

In the case of CREATE(), it is somewhat orthogonal.  Filesystem state
vs. protocol state.  Versions 2/3 have the same issue in that if an
application is in the middle of creating a file and then is
interrupted, that file may end up being created.  The client leaves it
as is and so does the server.

Spencer