Subject: [nfsv4] re: recalling delegation for setattr

From: [email-masked]
Date: Fri, 1 Apr 2005 11:53:09 -0500 (EST)

[Dave wrote]
> It is certainly a mistake, and I feel it needs to be addressed somehow.
> 
> People with delegations do sometimes have to change attributes and if
> they do and the stateid is zero, how does the server know not to recall
> the delegation?  If it does recall it, performance suffers.
> 
> What is "errata" is really unclear.  When Spencer sent out his message
...but clearly not a change like this (no pun intended:-)?

I suppose it can be argued that the RFC isn't wrong, since it is a performance
issue and not a correctness one.

Maybe this could be addressed in a "best practices" document. (I vaguely
recall Beepy mentioning plans for one?) It could recommend the client
either:
- return the delegation prior to the setattr
OR
- consider using the delegation stateid instead of all zeros (after all,
  it currently says "should", not "must") so that the server can avoid
  recalling the delegation

rick
ps: I recently looked at my server code and found that I'm not doing
    the recall at this time. I guess it's patchin time.

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

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 1 Apr 2005 11:13:30 -0800

>   it currently says "should", not "must") so that the server can avoid

I agree with this.  The client may provide the stateid.  THe structure
is ther for to and the server shouldn't penalize the client for sending
something a little "extra". 

Spencer