[nfsv4] Re: I-D Action: draft-ietf-nfsv4-uncacheable-directories-12.txt

[Rick Macklem <[e-mail]>]

On Thu, Oct 1, 2026 at 9:14 AM Chuck Lever <[e-mail]> wrote:
>
> Speaking as NFSv4 WG co-chair.
>
> Rick, thanks for your feedback.
>
> > I think I understand how this attribute is meant to be used and support
> > the concept. Having said that, I find the document complex/confusing/etc
> > and,it I implement the attribute in the FreeBSD client, I will largely ignore
> > what is in this document, as currently written.
>
> The chairs stated that a third WG Last Call on this document would
> follow -12. However, an implementer's statement that he would ignore
> the text bears on whether the document is actually ready for that Last
> Call. I understand well that your statement was not an objection to
> moving forward to publication.
>
> Before the Last Call opens, the chairs would like to know whether the
> implementation you have in mind would do what Section 5.1 of -12
> requires, or something different. The rule now in Section 5.1 is:
>
> >  If a directory object has the uncacheable dirent metadata attribute
> >  set, an honoring client MUST NOT satisfy a readdir of that directory
> >  from READDIR results obtained during a different enumeration, and
> >  MUST NOT report, for an entry, a value of a dirent metadata attribute
> >  that it received before the READDIR that most recently returned that
> >  entry, whatever operation supplied that value.
I did miss that during a first read of the draft, but am aware of the
requirement now.

>
> Previously you described the attribute as a "strong hint" to the
> FreeBSD client to use a READDIR COMPOUND instead of a READDIRPLUS.
> Section 5.1 allows a client to leave the attributes out of the
> READDIR ("or obtains them afterwards"), but only if the client then
> does not answer from attributes it already held.
Given the above, I think the FreeBSD client will ask for (type,
fileid, file_handle)
when doing the READDIR operation and will use the file_handle to invalidate
cached attributes for the file object that might change when the file
is written.

>
> My clarifying questions about the client as you would build it are:
>
> 1. An application enumerates the directory a second time, and the
>    directory's change attribute has not moved since the first pass.
>    Does the client send READDIR, or does it answer from the results
>    it cached on the first pass?
Hmm, good question.

At this time, I was thinking of not doing a second pass READDIR,
but I do see an argument for needing to do the READDIR again
in order to satisfy the above requirement of never using attributes
acquired before the readdir.
So, I'd say this is an open question and not one easily dealt with by
the draft, since it cannot really specify when a client chooses to do
a READDIR?

>
> 2. The READDIR did not request an entry's attributes, and an
>    application then stats that entry while the client's cached
>    attributes for the file are within their normal timeout. Does the
>    client send GETATTR, or does it answer from its attribute cache?
I'd say "answer from its attribute cache" unless the uncachable-file-data
attribute is set for the file object.

>
> 3. Is the answer to question 2 the same for every attribute, for
>    example mode and owner, or only for size, time_modify, and change?
>    Section 3 of -12 defines dirent metadata as every file attribute a
>    READDIR can return; you asked for "attributes that might change
>    when a file is written".
Actually, I was thinking that "attributes that might change when a file
is written" applies to the uncacheable-file-attibute attribute as well.

Attributes that do not change for the life of a file don't seem to be an
issue.  Attributes that might change due to SETATTR but not related to
writing the file's data (owner, owenr_group, mode..) do not seem to
be related to these uncachable attributes either, although I'll admit I
would have to re-read the uncachable file attribute draft again, to
see exactly what it says.

File attributes are a large grab bag which seem to be of three types:
1 - Never change for the life of a file object.
2 - Can be changed by SETATTR, but not related to the file object's data.
3 - Can change when a file's data is written.
It seems to be that both the uncachable-file-attribute and
uncachable-directory-attribute
are meant to affect caching of #3?

rick

>
> Let's document where your answers differ from Section 5.1 before the
> third Last Call opens, either as a defect in the text or as a
> (small oh) objection to the rule. Possibly Tom might not object to
> some changes to the language to accommodate -- at least it could be
> mentioned as one of the reasons a client might ignore a SHOULD.
>
>
> --
> Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)