[nfsv4] Re: non-WGLC review of draft-ietf-nfsv4-uncacheable-directories-10.txt

[Rick Macklem <[e-mail]>]

I've just chosen the last email in the thread. I am not commenting
specifically about Chunk's comments..

I'll assume that you have a directory where many of the file's are
being modified
(such that mtime, size, change are changing).  This is where I think
this attribute
is useful. (If not, ignore the rest of this post, because I do not
understand the goal.;-)

First, related to Jeff's comments w.r.t. "Why not just have Readdir ask for
the "uncachable file" attribute and use that".
-> To me, the problem with this is performance/efficiency related.
Suppose a client does a Readdir op. asking for (uncachable_file +
size, mtime, change..).
--> The server has to return (size, mtime, change..) although they are
relatively useless
      to the client if they cannot be cached. This is an inconvenience
for the client, but could
      be a large performance hit for the server, if it is a ffv1 pNFS
server, for example.

Now, wearing my FreeBSD client implementer hat..
For NFSv3, there are Readdir and ReaddirPlus RPCs.
The client uses the latter to acquire attributes that it can use to
prime caches.

For NFSv4, the FreeBSD client does roughly the same, using two different
compounds.
Since, the attributes beyond (fileno and type) are not needed to create POSIX
"struct dirent" entries, the only reason to do a ReaddirPlus compound is to
prime caches.

Bottom line. As I see it, this attribute makes a "strong hint" to the FreeBSD
NFSv4 client to use the Readdir compound instead of the ReaddirPlus one.
--> Simple. What am I missing here?

If my assumption of how it is used in the client is correct, then all you need
is a simple description of it.
--> I already suggested describing it as a "strong hint" of what
attributes should
     be requested for a Readdir. I know Tom didn't want to enumerate them, but
     if that really is a problem, you can define the attribute as an
attribute bitmap
     instead of just a boolean.

rick

On Wed, Sep 2, 2026 at 12:27 PM Chuck Lever <[e-mail]> wrote:
>
> On Wed, Sep 2, 2026, at 1:55 PM, Thomas Haynes wrote:
> > Agreed on ownership -- see the definition below.  One correction,
> > though: fattr4_uncacheable_file_data does not control that cache.
> > draft-ietf-nfsv4-uncacheable-files governs the data cache --
> > write-behind and read caching, its Section 4 -- and says nothing
> > about the attribute cache.
>
> Fair enough. I conflated the two drafts' targets. But this leaves
> us with neither attribute, as written, governing the cache where
> these attributes actually live.
>
>
> > It refers to the attrs field -- the fattr4 in your entry4 above.
> > Not the cookie, not the name.
> >
> > The fattr4 belongs to the object the entry refers to, not to the
> > parent. That is stated in the definition, not just implied:
>
> The remaining problem is that the normative requirement has nothing
> to attach to in real NFS clients. Section 5 makes three commitments:
>
> 1. "the client MUST retrieve dirent metadata from the server on each
>    READDIR rather than serving the response from a local cache"
>
> 2. "an honoring client may continue to cache the dirents themselves,
>    validated by the directory's change attribute as it would be for
>    any other directory, and refetch only their metadata"
>
> 3. The attribute does NOT govern "[t]he client's per-file attribute
>    cache for individual children of the directory, populated by
>    direct GETATTR"
>
> No client I know of keeps READDIR-returned fattr4s separate from
> fattr4s returned by GETATTR. READDIR-returned fattr4s only purpose
> is to prime the same per-file attribute cache that GETATTR replies
> land in. And applications in user space *never* *observe* READDIR
> attributes at all; they observe stat(2), served from that unified
> cache.
>
> Now run an honoring client through the three commitments:
>
> - It serves readdir(3) from cached dirent pages, validated by the
>   parent's change attribute, per (2). Writes to a child do not move
>   the parent's change attribute, so that cache stays valid.
>
> - No READDIR goes on the wire, so the MUST in (1), scoped to "each
>   READDIR", imposes nothing.
>
> - Every attribute the application sees comes from the per-file
>   attribute cache, which (3) says this attribute does not govern.
>
> Fully compliant, and every stat(2) result stale. The escape hatch in
> (2), "refetch only their metadata", has no operation to ride on:
> without a READDIR, refetching a child's metadata is a GETATTR, and
> its result lands in the cache that (3) carves out. The "externally
> visible behavior is equivalent" clause does not rescue it either:
> equivalence is measured against (1), and (1) as scoped requires
> nothing.
>
> Meanwhile a client that does what the Section 2 deployments need --
> treat its cached attributes for the directory's entries as invalid
> each time an application enumerates the directory -- is implementing
> behavior that Section 5 explicitly places outside the attribute's
> scope.
>
> The intended behavior is implementable and cheap. The stated
> requirement is not, because it attaches to a cache no client has
> and disclaims the one they all have. Here's a potential restatement
> of the normative text:
>
>    When the attribute is set on a directory and the client honors
>    it, the client MUST treat any file attributes it holds for the
>    directory's entries as invalid at the time it performs each
>    enumeration of the directory, regardless of which operation
>    populated them. Attributes obtained for an individual entry at
>    other times remain governed by the attribute caching rules of
>    [RFC8881] Section 10.6.
>
> The second sentence is what the current per-file-cache bullet is
> trying to say. The first is what the MUST needs to say for a
> unified-cache client to have anything to implement.
>
> Note that I'm not advocating for this replacement, necessarily,
> since I'm not convinced that this restatement makes a client
> behave the way you actually intend it to. It only makes the draft
> implementable on the current cohort of conventional POSIX-based
> clients.
>
>
> --
> Chuck Lever (author, nfsv4 co-chair)
>
> _______________________________________________
> nfsv4 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]