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: <OFDF554660.DF3A0BAE-ON87256D13.005DAD5E@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
Date: Fri, 25 Apr 2003 12:25:26 -0500

Dave,

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.

Perhaps the protocol should have used a separate mechanism to establish 
the open owner and its associated sequence ID instead of piggy backing it 
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.

Of course I guess its too late since changing the protocol doesn't seem to 
be an option. I wonder if there is something that could be done in a minor 
version. That may be hard to do without backward compatibility issues.

Carl Burnett
AIX Kernel Architecture - Distributed File Systems
(512) 838-8498, TL 678-8498
(please reply to cburnett@us.ibm.com)

"Noveck, Dave" <Dave.Noveck@netapp.com>
04/25/2003 11:48 AM

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

> If the server receives an OPEN for an unchecked create that indicates 
the 
> file should be truncated (size attribute 0), and the file exists, and 
the 
> OPEN requires an OPEN_CONFIRM, it is assumed that the truncate should 
not 
> occur. 

That's a desirable property but I don't think it is a required one.
I know my current code does the truncate immediately.  I think this
was discussed a bit at Connectathon.  My memory (which is probably
not all that reliable) was that Spencer said that his server does the
truncate immediately as well.  Spencer, can you confirm or deny?

The argument that the trncate should not be done immediately is
fairly clear.  If the open is not confirmed, then it is replay 
(which was not detected by the reply cache), so the open should 
not happen, including the truncate which is part of the open.

The counter-argument to that (besides the whiny "Gosh that is a
pain to do") is to ask why open-confirm and the sequence stuff 
exist and are restricted to OPEN, LOCK, etc.  For a large part 
of the protocol there is no replay protection within the protocol
itself.  People do reply caches as an implementation thing
and they seem to work most of the time, but there is no proof or
guarantee that they work.  In particular, note that a TRUNCATE via
a SETATTR has no specific replay protection within the protocol.
Only state-managing operations have this special level of protectioon.
This partly because of their special place in the protocol, i.e.
that other stuff depends on them working.  It is partly because
these are new ops that could be designed to incorporate the 
protection.  And is partly that nobody was really up to design
and debug such operations, that maintain state, when every
single request might be a replay.  It's just too hard.  So the
argument would be that doing the truncate immediately is no worse
than not having replay protection on SETATTR truncate, while 
you still maintain the sequencing as it relates to state management.

> I think this means the server (state manager) must record that the 
> file should be truncated when the OPEN_CONFIRM is sent by the client.

I think that's nice, but it leads to complexities.  One is what
happens if someone else reads or writes the file before the confirm
either happens or is timed out.   Do you have to wait to see if the 
truncate really has happened? 

Another issue in that same vein is what if the open that is being 
confirmed is a deny-write open.  Do you deny another open for write
that occurs before confirm or do you force that open to wait?  Right
now I do an immediate deny, but I'm leaning to the view that that is
bug.

Getting back to the truncate, you have the case in which the server
reboots before confirmation happens or times out.  Should the file
be truncated after the reboot?  I think the answer is probably that
it doesn't have to be (even if you go down this path) but I won't 
swear to that. 

> Assuming that is correct, what should happen if the truncate fails (for 
> example EACCES)?

I don't think it can.  I think it is up the server to verify that the
truncate can be done, when he accepts the open with truncate and give
the error back at that point.  If you defer the truncate, then once 
you accept it, you are committed to doing it, and have accepted that 
he (the principal doing the open) is allowed to do it.  When the 
confirm happens, you act on that determination.

> Should the state manager cleanup up the pending open state?
>
> What error should be returned? The OPEN_CONFIRM return values are pretty 

> limited (no NFS4ERR_EACCESS).

Because you are only confirming something, not doing something else
substantive.  If somethng like truncate appears to happen (because it
is now confirmed) as a result of that, it has to happen without 
a specfic error code that refers to that action.

My big regret is that v4 does not have a robust replay protection 
mechanism that works for everything uniformly, including OPEN 
(truncate or not) and SETATTR.  When we were considering the 
basic outlines of v4, it just seemed too hard to do.  The DAFS 
experience proves otherwise, however.

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