On 29 May 2019, at 13:19, Trond Myklebust wrote: > On Wed, 2019-05-29 at 12:39 -0400, Benjamin Coddington wrote: >> On 29 May 2019, at 12:21, Trond Myklebust wrote: > > Sorry, but that's not the case, because of the abuse of the > nosharecache flag. You are manipulating the file on the server and > expecting an immediate cache invalidation. That would require > information that the client does not have. Yes, forget about the nosharecache flag. Let's just assume we move the file on the server. The client does perform a GETATTR and sees the updated change_attr for the directory, but it matches the dentry's new d_time. I don't expect immediate cache invalidation; invalidation will never happen as long as B/'s change_attr isn't bumped again. On the client, B/foo dentry's d_time is the same as the change_attr for B/, and even though there's no file at B/foo on the server, the client will keep the B/foo dentry until something else bumps B/'s change_attr. Maybe I need to imagine a scenario where this matters more.. But, I think that if we use the method of comparing d_time with the parent's change_attr to determine if we need to lookup, this is a case where that's not reliable. I'll try to come up with something as I have time to work on it since I am getting pressure about it. It looks to me like this behavior has been around for a long time. Thanks for the look. Ben
