Re: client lookup_revalidate bug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 30 May 2019, at 6:35, Benjamin Coddington wrote:

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.

Takayuki Nagata points out that this behavior only happens when we have a
read delegation, and it seems obvious that we ought to skip lookup
revalidation if so.

Let me see if I can clarify the order of events so anyone that wishes can
better argue about what should happen.

Single client, NFS is mounted on /mnt

Client reads /mnt/A/foo, dentry A/foo is hashed.
Client moves /mnt/A/foo to /mnt/B/foo, dentry B/foo is hashed.
Server moves B/foo back to A/foo.
Client reads A/foo, gets a read delegation.
Client looks up B/foo, skips revalidation because it holds the read delegation.

Client will always return a positive lookup for both A/foo and B/foo at this
point.

Should this happen?  My position is no, it shouldn't.



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux