Subject: RE: [nfsv4] Delegation recall with truncate set

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 5 Aug 2003 11:27:19 -0700

Right, but how might a server know that?  The only way
I can see is that he simply does not return DELAY when 
such a SETATTR is done.  The problem with a server 
deciding to do that is that some clients depend on 
getting that DELAY return, don't they?

The server cannot adopt a strategy of returning DELAY
only if the recall is takes too long, because, at the
time he does the recall, he can only do the recall for 
truncation if he knows he wil never return DELAY, and it 
doesn't appear that he can know that.

I think the problem here is the semantics of the DELAY
return.  Although the spec text isn't very clear on this,
I think it is reasonable to assume that when you get back
DELAY you are being told that the truncate/REMOVE did not 
get done and that if you don't redo them, they wil not be
done.  Maybe we need DELAYED_AND_MAYBE_DONE which allows
the operation requested to be completed.  The problem is
that this doesn't fit the RPC re-issue model since a 
re-issued REMOVE might get NOENT.  Sigh!

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Tuesday, August 05, 2003 8:21 AM
To: [email-masked]
Subject: Re: [nfsv4] Delegation recall with truncate set

If the server knows the SETATTR of size==zero is going to succeed and
DELAY is not being returned to the original SETATTR request, then the
delegation can be recalled for truncation.

On Fri, Khan, Saadia wrote:
> Isn't the same true for a setattr with size set to zero? So then when
> would truncate be ever set in the recall?
> 
> Saadia
> 
> > -----Original Message-----
> > From: Spencer Shepler [mailto:[email-masked]] 
> > Sent: Friday, August 01, 2003 1:53 PM
> > To: [email-masked]
> > Subject: Re: [nfsv4] Delegation recall with truncate set
> > 
> > 
> > 
> > On Fri, [email-masked] wrote:
> > > I painted myself into an interesting corner and I thought 
> > I'd check to 
> > > see if this made sense:
> > > 
> > > Client A - Has write delegation for file X
> > > Client B - Does a Remove file X
> > > 	- server sends Recall Callback with truncate True to Client A
> > > 	- replies NFSERR_DELAY to Client B
> > > 
> > > I realized that, if Client B crashes before retrying the 
> > Remove, the 
> > > modified data for X on Client A would be lost.
> > > 
> > > I can only see two ways around this:
> > > 1) Don't set truncate True (Yuch!)
> > > 2) Don't reply NFSERR_DELAY after sending the Recall 
> > Callback request
> > >    and just wait until the Recall happens (maybe waiting until the
> > >    delegation expires) before doing the Remove and replying 
> > NFS_OK to
> > >    Client B.
> > > 
> > > Does this make sense? Is there a better solution?
> > 
> > I chose the sequence you have except the truncate==false; 
> > your solution 1).  As you say, there is no guarantee that the 
> > remove will be retransmitted and potentially may be denied 
> > (if there is an intermediate access change).  Maybe not the 
> > cleanest with respect to transmitted data that will be 
> > discarded but it is the safest.
> > 
> > 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

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

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 5 Aug 2003 14:53:39 -0500

> getting that DELAY return, don't they?

I don't know of a client that depends on a response of DELAY.  The
calling context on the client will certainly be stuck waiting for a
response; with our rules about retransmissions, the client should be
careful in retransmitting (and is required to drop the TCP connection
to do so).  Therefore, it may be okay.  Obviously, the server would
need to take care in consuming resources for such an instance.  For a
traditional server where it may have a service thread tied to the
request, blocking the incoming while awaiting for the delegation
recall to occur may be too much of a resource burden.

> doesn't appear that he can know that.

That is correct; it is not deterministic.

> re-issued REMOVE might get NOENT.  Sigh!

Right. I would not have interpreted DELAY in the "might-have-done"
way.  However, you are correct that there isn't enough descriptive
text for NFS4ERR_DELAY to make its semantics clear to a new reader.  I
will put this on the list of interpretation items to be covered.

Spencer