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

cburnett@us.ibm.com

Subject: Re: [nfsv4] Out of sync stateid scenario that looks difficult to resolve
Message-ID: <OF8946309C.CB8FFBA3-ON87256D9F.004DD274@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
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 cburnett@us.ibm.com)

Spencer Shepler <spencer.shepler@sun.com>
Sent by: nfsv4-admin@ietf.org
09/11/2003 06:28 PM
Please respond to spencer.shepler

        To:     nfsv4@ietf.org
        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
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4