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

From: "Khan, Saadia" <[email-masked]>
Date: Fri, 1 Aug 2003 15:07:17 -0700

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

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 5 Aug 2003 07:21:12 -0500

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.