Subject: RE: [nfsv4] question about OPEN (for truncate), and OPEN_CONFIRM

From: Carl Burnett <[email-masked]>
Date: Fri, 25 Apr 2003 14:43:24 -0500

Mike,

Your points are well taken. It still feels strange, even though I accept 
the technical rational. The round trip aspects are interesting. It assumes 
a particular client approach for open owners. One that is not very optimal 
for the wire or friendly to servers.

Carl

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

Mike Eisler <[email-masked]>
04/25/2003 01:58 PM

        To:     [email-masked], Carl Burnett/Austin/IBM@IBMUS
        cc:     [email-masked]
        Subject:        RE: [nfsv4] question about OPEN (for truncate), and OPEN_CONFIRM

Carl Burnett wrote,

> I can live with your response ( also Mike E's) - that is just do the 
> truncate, but I don't think this is good behavior. Basically, what could 

> turn out to be an illegitimate open request has been successful in 
> changing file system state. BTW: wouldn't the truncate via SETATTR case 
be 
> somewhat handled because it requires a valid stateid.

What is not legitimate? The request has a valid client id, and a valid
and authorized principal. If a file is truncated or create without open
confirmation, then that's the fault of the client implementation for
not constructing and sending a valid OPEN_CONFIRM on a timely basis.
Even if the client follows up with OPEN_CONFIRM too late (say because
of a network partition, which is certainly not the client's fault), it
can still start from the beginning with OPEN. If the OPEN was doing a
truncate, the file is still truncated. If it was doing an exclusive
create, the client's verifier will match.  So, only a broken client
implementation messes things up here.

> Perhaps the protocol should have used a separate mechanism to establish 
> the open owner and its associated sequence ID instead of piggy backing 
it 

One issue is that the client might have not used the open owner for a
long time, and the so the server has disposed of it. The server is in a
better position to indicate whether the open owner is good or not. An
NFS4ERR_EST_OPEN_OWNER code from OPEN would be an alternative to
address this, but it would also result in more round trips. The
thinking is that because the open owner is associated with a distinct
process id, a common scenario is that the client has processes that
open one file, do their thing, close, and exit. As it is now, two round
trips are needed for that scenario. The NFS4ERR_EST_OPEN_OWNER results
in three round trips.

> on open. Another approach might have been for the OPEN have no effect if 
a 
> confirm is required. The client would then do the OPEN_CONFIRM to 
complete 
> its state handshake, and then it would make the original OPEN request 
> against to get its file system work done.

Three round trips.

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

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 28 Apr 2003 20:36:29 -0500

> for the wire or friendly to servers.

But it may be what the client needs to differentiate based on process
to the server to support items like OPEN(share_deny) properly.  If the
open_owner is associated with a user/credential instead of
process/credential, then two applications executing on behalf of that
user/credential would not be able to function properly with respect to
OPEN(share_deny).  This assumes that the APIs at the client support
deny modes to begin with.

Spencer

-- 
Spencer