Zusammenfassung

  • Bei einem markierten Verzeichnis darf ein beachtender Client eine neue Aufzählung nicht aus READDIR-Ergebnissen einer anderen Aufzählung bedienen und für einen Eintrag keinen Wert melden, der vor dem jüngsten READDIR für diesen Eintrag empfangen wurde.
  • Die Vorschrift betrifft das beobachtbare Ergebnis, nicht das Vorhandensein des Caches. Sie ist pfad- und eintragsbezogen und lässt einen neueren Wert beim Inhaber einer Schreibdelegation bestehen.
  • Der Mechanismus kann falsche Entscheidungen von Backup- und Synchronisationsläufen vermeiden, erzeugt aber wiederkehrende Metadatenlast und liefert dem Server keinen Beleg, dass jeder Client ihn einhält.

Der Fehler liegt zwischen zwei gültigen Zuständen

Ein NFS-Client kann ein korrektes Verzeichnisbild besitzen und trotzdem falsche Auskünfte über dessen Dateien geben. Name und fileid eines Eintrags bleiben stabil, solange niemand den Eintrag anlegt, löscht oder umbenennt. Ein anderer Client kann jedoch in die bereits benannte Datei schreiben und dadurch size, time_modify, time_metadata oder time_access verändern, ohne das change-Attribut des Verzeichnisses zu bewegen.

READDIR kann diese Dateiattribute zusammen mit den Einträgen liefern. Der Client behält sie, damit ein späteres stat nicht für jede Datei einen GETATTR erzeugt. RFC 8881 erlaubt eine zeitlich begrenzte Wiederverwendung. In einem HPC-Ausgabeverzeichnis oder einer stark parallelen Ingest-Zone können Schreibvorgänge schneller eintreffen als jede sinnvolle positive Cache-Lebensdauer.

Die Folge kann Daten betreffen: Ein inkrementelles Backup oder ein Verzeichnisabgleich entscheidet anhand alter Größe und Änderungszeit, dass nichts zu kopieren sei. fattr4_uncacheable_dirent_metadata gibt dem Server ein verzeichnisbezogenes Signal, um eine neue Beobachtung pro Durchlauf zu verlangen. Ein nicht gesetztes Attribut bestätigt dagegen nicht die Zuverlässigkeit gewöhnlicher Caches.

Revision 11 ersetzt Cache-Rhetorik durch eine Prüfregel

draft-ietf-nfsv4-uncacheable-directories-11 wurde am 5. September 2026 eingereicht. Es ist ein aktives Standards-Track-Dokument der NFSv4-Arbeitsgruppe. Der Implementierungsabschnitt berichtet von Hammerspace- und Linux-Prototypen. Das ist weder eine RFC noch eine IETF-Genehmigung oder ein Nachweis heutiger Produktionsverbreitung.

Revision 10 verlangte, Metadaten „bei jedem READDIR“ vom Server zu holen. READDIR ist jedoch schon die Netzwerkoperation zum Server. Die Formulierung schloss nicht sauber aus, dass ein Client neue Namen erhält und anschließend eine ältere Größe aus seinem normalen Inode-Attributcache meldet.

Revision 11 definiert zwei sichtbare Verbote. Eine neue Aufzählung darf nicht mit READDIR-Ergebnissen einer früheren Aufzählung erfüllt werden. Gibt das jüngste READDIR einen Eintrag zurück, darf für ihn kein Attributwert gemeldet werden, den der Client vor diesem READDIR erhalten hatte — gleichgültig, welche Operation den Wert ursprünglich in den Cache brachte.

Ein Konformitätstest braucht damit keinen Blick in den Kernel. Erstes Aufzählen, paralleles Vergrößern der Datei durch einen anderen Client, zweites Aufzählen, dann stat: Verboten ist der Wert von vor dem READDIR des zweiten Durchlaufs. Ob der Client ihn intern löscht, überschreibt, versioniert oder behält, ist unerheblich, solange er ihn nicht als neue Antwort ausgibt.

Ein Durchlauf ist nicht ein Paket je Name

Die überarbeitete Begriffswahl verhindert eine teure Fehlinterpretation. Kleingeschriebenes readdir bezeichnet die Anforderung der Anwendung; READDIR die NFSv4.2-Operation. Eine enumeration ist ein Durchlauf durch das Verzeichnis. Sie umfasst meist viele Anwendungsaufrufe und bei großen Verzeichnissen mehrere fortgesetzte READDIRs. Ein READDIR versorgt normalerweise zahlreiche readdir-Aufrufe.

Der Entwurf fordert daher nicht eine Netzwerkrunde pro Eintrag. Er fordert, dass der aktuelle Durchlauf von READDIRs dieses Durchlaufs getragen wird. Der Client sollte die später gemeldeten Attribute im attr_request anfordern. Nachträgliche GETATTRs sind möglich, kosten aber einen Aufruf pro Eintrag und zerstören den Verkehrsvorteil.

Nach Ende des Durchlaufs dürfen die Werte im Cache bleiben. Zwischen Durchläufen gelten die üblichen Lebensdauerregeln. Erst wenn der nächste Durchlauf den Eintrag wieder per READDIR liefert, wird ein älterer Wert für diese Antwort unzulässig. „Uncacheable“ beschreibt damit eher eine Altersgrenze für Aussagen als ein Speicherverbot.

Eine Umschaltung hat keine gemeinsame Uhr

Setzt der Server das Attribut auf TRUE, kennt ein Client mit gecachten Verzeichnisattributen die Änderung noch nicht. Er darf sein bisheriges Verhalten fortsetzen, bis die obere Cache-Grenze abläuft oder eine Revalidierung die Änderung des Verzeichnis-change erkennt. Revision 11 macht diese Übergangszeit ausdrücklich sichtbar.

Für den Betrieb sind deshalb Server-Änderungszeit, erste Beobachtung pro Clientklasse und erste regelkonforme Anwendungsausgabe getrennte Ereignisse. Ein Konfigurationsdashboard, das nur den ersten Zeitpunkt speichert, beweist keine Wirkung.

Auch eine Verzeichnisdelegation muss beendet werden. Sie erlaubt dem Client, Einträge ohne Serverkontakt zu bedienen, während die neue Regel für jeden Durchlauf einen Serverpfad verlangt. Bei gesetztem Attribut muss der Server bestehende Delegationen zurückrufen und darf keine neuen erteilen. Benachrichtigungen über Kindattribute sind kein allgemeiner Ersatz: Sie sind optional, oft nicht implementiert und skalieren im ungünstigen Fall mit Clients mal Änderungen.

Neuheit folgt der Schreibautorität

Ein Client mit OPEN_DELEGATE_WRITE kann size oder change in einer neueren Fassung besitzen als der Server. RFC 8881 lässt den Server diese Werte per CB_GETATTR beim delegierten Client abfragen. Würde der Client seine neuere Kenntnis durch die ältere Serverkopie ersetzen, hätte die vermeintliche Auffrischung den Zustand verschlechtert.

Revision 11 nimmt diesen Fall aus. Das Verbot richtet sich gegen Werte, die älter sind als das, was der Server liefern würde; es zwingt den Delegationsinhaber nicht zum Rückschritt. Frische hängt damit von zuständiger Schreibautorität und Beobachtungszeit ab, nicht bloß von der Richtung eines Netzwerkaufrufs.

Auch der jüngste READDIR-Wert kann unmittelbar danach altern. Die Erweiterung bietet keinen atomaren, verteilten Snapshot von Daten und Metadaten. Sie verhindert die klar umrissene Falschzuordnung einer bereits alten Messung zum neuen Durchlauf.

Das Signal gehört zum Pfad

Das Attribut sitzt auf einem Verzeichnis und betrifft Einträge, die durch dieses Verzeichnis aufgezählt werden. Ist dieselbe Datei in ein markiertes und ein unmarkiertes Verzeichnis hart verlinkt, bleibt der unmarkierte Pfad unbeeinflusst. Eine automatische Vererbung an Unterverzeichnisse definiert das Protokoll ebenfalls nicht; sie wäre lokale Serverpolitik.

Die Typbehandlung wurde korrigiert. Weil die Unterstützung pro Dateisystem angekündigt wird, muss GETATTR auf einem Nicht-Verzeichnis FALSE liefern. SETATTR auf dem falschen Objekttyp führt zu NFS4ERR_WRONG_TYPE. Unterstützte Erweiterung und sinnvolle Anwendbarkeit auf dieses Objekt sind unterschiedliche Aussagen.

Attributkenntnis ist kein Einhaltungsbeleg

Das Attribut ist beratend. Ein beobachtetes GETATTR oder SETATTR beweist nur, dass ein Client die Kennung kennt. Es beweist nicht, dass er beide Meldeverbote durchsetzt. Der Server kann daraus einen beachtenden, einen bewusst ignorierenden und einen unwissenden Client nicht unterscheiden. Seine eigene Korrektheit darf deshalb keine universelle Befolgung voraussetzen.

Der Preis ist absichtlich spürbar. Jeder neue Durchlauf eines markierten Verzeichnisses erzeugt Serverarbeit; ein Nur-Namen-READDIR mit einzelnen GETATTRs ist noch teurer. Darf ein unprivilegierter Benutzer das Attribut auf einem heißen Baum setzen, kann eine Metadatenänderung Last auf alle beachtenden Clients vervielfachen. Berechtigung, Exportpolitik und Kapazitätsbudget gehören zur Kontrolle.

Die Quellen belegen Entwurfstext, Revisionsgeschichte, RFC-Grundlagen, öffentliche Commit-Begründungen und gemeldete Prototypen. Sie belegen keine ausgelieferte Linux-Version, kein Hammerspace-Produktverhalten, keine Verbreitung, Messung, Störung oder Wirkung. Der separate Entwurf zu uncacheable file data behandelt Inhalt und Dauerhaftigkeit und erweitert diese Metadatenregel nicht.

In Heng Lus Realitätsschichten sind Serverattribut, privater Clientzustand, READDIR-Beobachtung und Anwendungsaussage eigenständige Tatsachen. Revision 11 ist besser, weil sie den Übergang bestimmt, ohne diese Tatsachen gleichzusetzen.

Quellen