On Tue, Jun 4, 2019 at 8:57 AM Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > On Tue, 2019-06-04 at 08:41 -0400, Benjamin Coddington wrote: > > Hey linux-nfs, and especially maintainers, > > > > I'm still interested in working on a problem raised a couple weeks > > ago, but > > confusion muddled that discussion and it died: > > > > If the client holds a read delegation, it will skip revalidation of a > > dentry > > in lookup. If the file was moved on the server, the client can end > > up with > > two positive dentries in cache for the same inode, and the dentry > > that > > doesn't exist on the server will never time out of the cache. > > > > The client can detect this happening because the directory of the > > dentry > > that should be revalidated updates it's change attribute. Skipping > > revalidation is an optimization in the case we hold a delegation, but > > this > > optimization should only be used when the delegation was obtained via > > a > > lookup of the dentry we are currently revalidating. > > > > Keeping the optimization might be done by tying the delegation to the > > dentry. Lacking some (easy?) way to do that currently, it seems > > simpler to > > remove the optimization altogether, and I will send a patch to remove > > it. > > A delegation normally applies to the entire inode. It covers _all_ > dentries that point to that inode too because create, rename and unlink > are always atomically accompanied by an inode change attribute. > > IOW: The proposed restriction is both unnecessary and incorrect. If the delegation also applies to the dentry, then in the described case where the directory was being modified, isn't it then the server's responsibility to recall that delegation. Would that have prevented this problem? Also reading thru the rfc7530, I don't see where it says that dentry attributes are also delegated on a read/write delegation. Also, while the open, create, rename, unlike carry the before/after change attribute for the directory, I think there are no guarantees of that attribute after the open (even with the delegation). RFC 7530 1.4.6 snippet : "When the server grants a delegation for a file to a client, the client is guaranteed certain semantics with respect to the sharing of that file with other clients. " All this is about sharing and IO access to the file. Prior to that it talks about time-based attribute cache for file and directory attributes same as in previous NFS versions. I don't see any mention or implications that directory attributes are cached for the file delegations. > > Any thoughts on this? Any response, even asserting that this is not > > something > > we will fix are welcome. > > -- > Trond Myklebust > Linux NFS client maintainer, Hammerspace > trond.myklebust@xxxxxxxxxxxxxxx > >
