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

cburnett@us.ibm.com

Subject: RE: [nfsv4] question about OPEN (for truncate), and OPEN_CONFIRM
Message-ID: <OF33F7881A.87782BA2-ON87256D13.0069AB5A@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
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 cburnett@us.ibm.com)

Mike Eisler <mike@eisler.com>
04/25/2003 01:58 PM

        To:     Dave.Noveck@netapp.com, Carl Burnett/Austin/IBM@IBMUS
        cc:     nfsv4@ietf.org
        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
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4