public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Haynes <loghyr@gmail.com>
To: Anna Schumaker <anna@kernel.org>
Cc: Tom Haynes <loghyr@gmail.com>,
	linux-nfs@vger.kernel.org,  Trond Myklebust <trondmy@kernel.org>,
	Jeff Layton <jlayton@kernel.org>,
	 Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [PATCH 1/1] nfs: don't skip revalidate on directory delegation when attrs flagged stale
Date: Thu, 23 Apr 2026 07:29:29 -0700	[thread overview]
Message-ID: <aeosOBEN-RWr1_Ae@mana> (raw)
In-Reply-To: <32c25063-3b89-4d00-87c5-3334327586c3@app.fastmail.com>

On Thu, Apr 23, 2026 at 09:37:21AM -0800, Anna Schumaker wrote:
> Hi Tom
> 
> On Sat, Apr 18, 2026, at 3:03 PM, Tom Haynes wrote:
> > On a local directory mutation (rename/create/unlink) the client marks
> > CHANGE / MTIME / CTIME as invalid in NFS_I(dir)->cache_validity.  When
> > a subsequent stat(2) enters __nfs_revalidate_inode() and finds a
> > directory delegation held, the function currently early-exits and
> > returns the cached (now stale) mtime to userspace without sending a
> > GETATTR RPC.
> >
> > Keep the early-exit for the fast path, but take the RPC when CHANGE,
> > MTIME, or CTIME are already marked invalid.  The delegation alone is
> > not a guarantee of cached-attr freshness once the code itself has
> > flagged the cache as stale.
> 
> Is this a problem only for the attributes you've flagged, or do you think
> it would be a problem for size, nlink, or mode attributes as well? I'm asking
> because we have NFS_INO_INVALID_ATTR which includes all of these attributes
> which might make this a little more generic rather than carving out an
> exception an attribute at a time.

Hey Anna,

Agreed on at least size (and probably atime), which means a little
more generic would be a good thing.

Tom

> 
> Thoughts?
> Anna
> 
> >
> > Assisted-by: Claude:claude-opus-4-7 [bpftrace] [tshark]
> > Signed-off-by: Tom Haynes <loghyr@gmail.com>
> > ---
> >  fs/nfs/inode.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
> > index 98a8f0de1199..936bc329f462 100644
> > --- a/fs/nfs/inode.c
> > +++ b/fs/nfs/inode.c
> > @@ -1390,7 +1390,11 @@ __nfs_revalidate_inode(struct nfs_server 
> > *server, struct inode *inode)
> >  		status = pnfs_sync_inode(inode, false);
> >  		if (status)
> >  			goto out;
> > -	} else if (nfs_have_directory_delegation(inode)) {
> > +	} else if (nfs_have_directory_delegation(inode) &&
> > +		   !(NFS_I(inode)->cache_validity &
> > +		     (NFS_INO_INVALID_CHANGE |
> > +		      NFS_INO_INVALID_MTIME  |
> > +		      NFS_INO_INVALID_CTIME))) {
> >  		status = 0;
> >  		goto out;
> >  	}
> > -- 
> > 2.53.0

-- 
---
Tom Haynes <loghyr@gmail.com>

      reply	other threads:[~2026-04-23 14:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-18 19:03 [PATCH 0/1] nfs: fix directory mtime staleness under directory delegation after local mutations Tom Haynes
2026-04-18 19:03 ` [PATCH 1/1] nfs: don't skip revalidate on directory delegation when attrs flagged stale Tom Haynes
2026-04-23 13:37   ` Anna Schumaker
2026-04-23 14:29     ` Thomas Haynes [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aeosOBEN-RWr1_Ae@mana \
    --to=loghyr@gmail.com \
    --cc=anna@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox