Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <6C2EF3B8-568A-41F0-B134-52996457DD7D@redhat.com> <c133a2ed862bf5714210aa5a44190ddaecfa188f.camel@hammerspace.com>
In-Reply-To: <c133a2ed862bf5714210aa5a44190ddaecfa188f.camel@hammerspace.com>
From:   Olga Kornievskaia <aglo@umich.edu>
Date:   Mon, 10 Jun 2019 13:08:53 -0400
Message-ID: <CAN-5tyHiXOybuiTNAVABWQH2YQczMYG7tHGey3ZaReo8F0gY4A@mail.gmail.com>
Subject: Re: client skips revalidation if holding a delegation
To:     Trond Myklebust <trondmy@hammerspace.com>
Cc:     "bcodding@redhat.com" <bcodding@redhat.com>,
        "anna.schumaker@netapp.com" <anna.schumaker@netapp.com>,
        "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

On Tue, Jun 4, 2019 at 8:57 AM Trond Myklebust <trondmy@hammerspace.com> 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@hammerspace.com
>
>