Adding an Uncacheable Directory-Entry Metadata Attribute to NFSv4.2

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 29 December 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Clients of remote filesystems may cache directory-entry metadata to improve performance. This caching presumes that directory contents and the attributes of its entries remain stable for the duration of a client cache lifetime. In some deployments that presumption does not hold; the conditions under which this is the case for the deployment that motivates this work are described in Section 2.¶

In this document, the term directory is used to describe the context in which directory entries are retrieved. The uncacheable dirent metadata attribute applies to the caching of directory-entry metadata, including names and associated file object metadata such as size and timestamps. It does not prohibit caching of the directory object itself, nor does it affect caching of file data.¶

Caching of directory-entry metadata can result in incorrect size and timestamp information when files are modified concurrently, reducing the effectiveness of uncacheable file data semantics ([I-D.ietf-nfsv4-uncacheable-files]) when directory-entry metadata is stale. This can lead to applications observing inconsistent metadata and data views even when file data caching is disabled.¶

This document introduces the uncacheable dirent metadata attribute to NFSv4.2 to allow servers to advise clients that caching of directory-entry metadata is unsuitable. Using the process detailed in [RFC8178], the revisions in this document become an extension of NFSv4.2 [RFC7862]. They are built on top of the external data representation (XDR) [RFC4506] generated from [RFC7863].¶

2. Deployment Motivation

A class of deployment exposes a single file namespace concurrently through multiple file-access protocols, typically including NFSv4.2, NFSv3, and the Server Message Block (SMB) protocol family [MS-SMB2]. The same directories are reachable from all of those protocols and, in many such deployments, from server-side policy components (placement, replication, archival, tiering) that act on the namespace without a client connection. Changes to a directory's contents -- entries added, entries removed, entries whose attributes have been updated -- may therefore originate at any time from any of those sources.¶

NFSv4.2 client implementations typically cache directory-entry metadata returned by READDIR for a period bounded by either the directory's change attribute or a heuristic timeout. In deployments of the kind described above, the rate of server-side directory churn can exceed what those caches can track, so that an NFSv4.2 client serving READDIR responses from its local cache will, with some regularity, return entries or attribute values that no longer reflect the current state of the directory at the server.¶

The fattr4_uncacheable_dirent_metadata attribute is the server's mechanism to identify a directory for which this risk is high enough that client-side caching is not safe. When the server sets the attribute on a directory, an honouring client retrieves directory-entry metadata from the server on each READDIR rather than from a local cache.¶

In the deployments that motivate this work, no attribute values returned for a given dirent vary across users. The server returns the same set of entries with the same attribute values to all NFSv4 clients of a given directory regardless of the requesting user's identity.¶

The SMB protocol family includes a related concept called Access-Based Enumeration (ABE) [MS-ABE] [MS-SMB2], in which an SMB server filters the visible set of directory entries by the requesting user's access rights. ABE is named here as background for readers familiar with the SMB ecosystem. The NFSv4.2 attribute defined in this document is not an NFS surface for ABE: it does not require, specify, or depend on per-user directory filtering, and the servers that motivate this work do not apply such filtering to NFSv4.2 READDIR responses.¶

3. Definitions

Access Based Enumeration (ABE)

A Server Message Block (SMB) [MS-SMB2] feature in which the server filters the visible set of directory entries by the requesting user's access rights [MS-ABE]. Used in this document only as background for readers familiar with the SMB ecosystem; the NFSv4.2 attribute defined here is not an NFS surface for ABE.¶

dirent

A directory-entry representing a file or subdirectory and its associated attributes.¶

dirent caching

A client-side cache of directory-entry names and associated file object metadata, used to avoid repeated directory lookup and attribute retrieval.¶

uncacheable dirent metadata attribute

An NFSv4.2 file attribute that advises clients not to cache directory-entry metadata associated with file objects, including names, size, and timestamps.¶

This document assumes familiarity with NFSv4.2 operations, attributes, and error handling as defined in [RFC8881] and [RFC7862].¶

4. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

5. Caching of Directory-Entry Metadata

The fattr4_uncacheable_dirent_metadata attribute is a read-write boolean attribute that applies to directory objects and has a data type of boolean. The attribute is not set on individual file objects and applies only to directory-entry metadata returned from the directory on which it is set.¶

The uncacheable dirent metadata attribute enables correct presentation of directory-entry metadata in deployments where directory contents may change at the server at a rate that exceeds the validity of typical client caches. As such, it is an OPTIONAL attribute to implement for NFSv4.2. If both the client and the server support this attribute, and the attribute is set on a directory, the client MUST retrieve directory-entry metadata from the server on each READDIR rather than serving the response from a local cache.¶

This document specifies the required observable behavior rather than mandating a particular internal implementation strategy. Clients MAY employ more sophisticated mechanisms, such as time-limited caches that revalidate against the server on each READDIR, provided that the externally visible behavior is equivalent to retrieving directory-entry metadata from the server on each READDIR.¶

Allowing clients to set this attribute provides a portable mechanism to request that directory-entry metadata not be cached, without requiring changes to application behavior or out-of-band administrative configuration.¶

A client can determine whether the uncacheable dirent metadata attribute is supported for a given directory by examining the supported_attrs attribute for that directory's filesystem or by probing support using the procedures described in [RFC8178].¶

The only way that the server can determine that the client supports the attribute is if the client sends either a GETATTR or a SETATTR with the uncacheable dirent metadata attribute.¶

The uncacheable dirent metadata attribute governs caching behavior of directory-entry metadata returned by READDIR and related operations, not the directory object itself.¶

The uncacheable dirent metadata attribute addresses a different aspect of client-side caching than fattr4_uncacheable_file_data ([I-D.ietf-nfsv4-uncacheable-files]). The file data attribute governs caching of file contents, while the dirent metadata attribute governs caching of directory-entry metadata returned by READDIR and related operations. The attributes are independent and may be used separately.¶

This attribute does not define behavior for positive or negative name caching or for caching of LOOKUP results outside the scope of directory-entry metadata returned by READDIR and related operations.¶

Directory delegations grant a client exclusive caching rights subject to server recall. In deployments where directory contents change at a rate that makes per-change recall impractical, a directory delegation does not provide the always-refetch semantics defined by the uncacheable dirent metadata attribute. These mechanisms are independent.¶

Clients MUST NOT assume that directory-entry metadata is valid beyond the READDIR that produced it.¶

6. Example: Directory Enumeration With and Without Dirent Metadata Caching

This example illustrates the difference in client-visible behavior when directory-entry metadata caching is enabled versus when the uncacheable dirent metadata attribute is set on a directory. In both scenarios, the set of entries in the directory does not change between the two calls; an attribute value of one entry is updated at the server between calls. The difference is whether the second call observes the updated attribute value.¶

Application             NFSv4.2 Client        NFSv4.2 Server
-----------             --------------        --------------
readdir("/dir")
   |
   |                     READDIR
   |-------------------->------------------------>
   |                     entries:
   |                       a (size=100)
   |                       b (size=200)
   |                       c (size=300)
   |<--------------------<------------------------
   |
(entries cached in client)

                                            (concurrent writer extends
                                             a from size=100 to
                                             size=500)

readdir("/dir")
   |
   |                     (no network traffic)
   |                     entries returned from
   |                     client cache:
   |                       a (size=100)
   |                       b (size=200)
   |                       c (size=300)

Application             NFSv4.2 Client        NFSv4.2 Server
-----------             --------------        --------------
readdir("/dir")
   |
   |                     READDIR
   |-------------------->------------------------>
   |                     entries:
   |                       a (size=100)
   |                       b (size=200)
   |                       c (size=300)
   |<--------------------<------------------------
   |
(no directory-entry metadata retained)

                                            (concurrent writer extends
                                             a from size=100 to
                                             size=500)

readdir("/dir")
   |
   |                     READDIR
   |-------------------->------------------------>
   |                     entries:
   |                       a (size=500)
   |                       b (size=200)
   |                       c (size=300)
   |<--------------------<------------------------

7. Implementation Status

Note to RFC Editor: please remove this section prior to publication.¶

There is a prototype Hammerspace server which implements the uncacheable dirent metadata attribute and a prototype Linux client which treats the attribute as an indication to retrieve directory- entry metadata from the server on each READDIR rather than from a local cache.¶

In the prototype, directories whose contents change at the server at a rate exceeding typical client cache lifetimes are marked with the fattr4_uncacheable_dirent_metadata attribute.¶

The Linux client decodes the attribute in fs/nfs/nfs4xdr.c into a per-inode flag (nfsi->uncacheable). The readdir path in fs/nfs/dir.c consults this flag to skip the readdir cache and refetch from the server on each readdir call. Clients may employ more sophisticated mechanisms, such as time-limited caches that revalidate against the server on each READDIR, provided that the externally observable behavior matches the always-refetch semantics described in this document.¶

At the time of writing, the prototype encodes the attribute on the wire alongside the companion file-data attribute defined in [I-D.ietf-nfsv4-uncacheable-files] as a single shared flag. A follow-on prototype branch separates the two attributes as the two documents specify.¶

Experience with the prototype indicates that the attribute enables servers to identify directories whose contents change faster than typical NFSv4.2 client cache lifetimes can track, while remaining compatible with existing NFSv4.2 semantics.¶

8. XDR for Uncacheable Dirents Attribute

///
/// typedef bool            fattr4_uncacheable_dirent_metadata;
///
/// const FATTR4_UNCACHEABLE_DIRENT_METADATA   = 88;
///

9. Extraction of XDR

This document contains the external data representation (XDR) [RFC4506] description of the uncacheable dirent metadata attribute. The XDR description is presented in a manner that facilitates easy extraction into a ready-to-compile format. To extract the machine-readable XDR description, use the following shell script:¶

#!/bin/sh
grep '^ *///' $* | sed 's?^ */// ??' | sed 's?^ *///$??'

For example, if the script is named 'extract.sh' and this document is named 'spec.txt', execute the following command:¶

sh extract.sh < spec.txt > uncacheable_prot.x

This script removes leading blank spaces and the sentinel sequence '///' from each line. XDR descriptions with the sentinel sequence are embedded throughout the document.¶

Note that the XDR code contained in this document depends on types from the NFSv4.2 nfs4_prot.x file (generated from [RFC7863]). This includes both nfs types that end with a 4, such as offset4, length4, etc., as well as more generic types such as uint32_t and uint64_t.¶

While the XDR can be appended to that from [RFC7863], the code snippets should be placed in their appropriate sections within the existing XDR.¶

10. Security Considerations

This attribute is not a security mechanism. It addresses correctness of client-side caching when client-cached directory-entry metadata can become stale relative to the current state of the directory at the server. It does not change NFSv4.2 authentication or authorization semantics, and it does not impose access controls on the entries it describes.¶

Authorization to set or modify the fattr4_uncacheable_dirent_metadata attribute is governed by existing NFSv4.2 authorization mechanisms. Servers MAY restrict modification of this attribute based on local policy, file ownership, or access control rules. This document does not define a new authorization model.¶

If the client supports Labeled NFS (see [RFC7204] for background), the client MUST locally enforce the MAC security policies defined by NFSv4.2 ([RFC7862], Section 9). This obligation is independent of whether directory-entry metadata is cached or refetched.¶

The uncacheable dirent metadata attribute allows servers to indicate that directory-entry metadata should not be assumed to remain valid beyond the READDIR that produced it.¶

11. IANA Considerations

This document has no IANA actions. Numbered FATTR4 attributes for NFSv4 are assigned by WG coordination through IETF publication rather than by an IANA registry, consistent with the assignment of attributes 81 and 82 in [RFC8275] and [RFC8276]. Attribute number 88 was selected on the NFSv4 working group mailing list in conjunction with the assignment of number 87 in [I-D.ietf-nfsv4-uncacheable-files].¶

12. References

Acknowledgments

Trond Myklebust, Mike Snitzer, Jon Flynn, Keith Mannthey, and Thomas Haynes all worked on the prototype at Hammerspace.¶

Rick Macklem, Chuck Lever, and Dave Noveck reviewed the document.¶

Chris Inacio, Chuck Lever, Brian Pawlowski, and Gorry Fairhurst helped guide this process.¶

Author's Address