From: Jeff Layton <jlayton@kernel.org>
To: Benjamin Coddington <ben.coddington@hammerspace.com>
Cc: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>,
Piyush Sachdeva <s.piyush1024@gmail.com>,
linux-nfs <linux-nfs@vger.kernel.org>,
Chuck Lever <cel@kernel.org>, trondmy <trondmy@kernel.org>,
sfrench@samba.org, sprasad@microsoft.com,
vaibsharma@microsoft.com
Subject: Re: NFS delegations behavior analysis
Date: Tue, 23 Jun 2026 09:40:03 -0400 [thread overview]
Message-ID: <509e5aecbccb57cd7cd033d45a0c28db8ba8b52c.camel@kernel.org> (raw)
In-Reply-To: <E86DDFB0-6E5E-40CC-8DFA-7233793D25E1@hammerspace.com>
On Tue, 2026-06-23 at 09:32 -0400, Benjamin Coddington wrote:
> On 23 Jun 2026, at 9:11, Benjamin Coddington wrote:
>
> > .... er - so with directory delegations, can we simply re-hydrate the dentry
> > cache from the directory page mappings if the delegation is still valid?
> > Does the directory delegation pin the mapping? Clearly I need to look at
> > the code..
>
> .. right - we don't keep the file attributes in the mappings today. And,
> more to the point - the directory delegation doesn't protect those file
> attributes either. We'd need NOTIFY4_CHANGE_CHILD_ATTRIBUTES implemented.
>
Which I think could be done, at least on the Linux server. fsnotify
does support watching for child attribute changes (FS_EVENT_ON_CHILD |
FS_ATTRIB).
That could be very chatty though. We would need to do the work to make
nfsd send callbacks >1 page in order to keep up, I imagine.
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2026-06-23 13:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-23 10:01 NFS delegations behavior analysis Piyush Sachdeva
2026-06-23 10:50 ` Jeff Layton
2026-06-23 11:04 ` Mkrtchyan, Tigran
2026-06-23 11:10 ` Jeff Layton
2026-06-23 13:11 ` Benjamin Coddington
2026-06-23 13:31 ` Daire Byrne
2026-06-23 13:32 ` Benjamin Coddington
2026-06-23 13:40 ` Jeff Layton [this message]
2026-06-23 13:59 ` Benjamin Coddington
2026-06-23 16:29 ` Trond Myklebust
2026-06-23 13:33 ` Jeff Layton
2026-06-23 13:11 ` Anna Schumaker
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=509e5aecbccb57cd7cd033d45a0c28db8ba8b52c.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=ben.coddington@hammerspace.com \
--cc=cel@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=s.piyush1024@gmail.com \
--cc=sfrench@samba.org \
--cc=sprasad@microsoft.com \
--cc=tigran.mkrtchyan@desy.de \
--cc=trondmy@kernel.org \
--cc=vaibsharma@microsoft.com \
/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