Zusammenfassung

  • fattr4_uncacheable_file_data beschreibt die gewünschte Behandlung auf dem Server, aber nicht den tatsächlichen Speicherzustand eines Clients.
  • Bei bereits geöffneten Dateien dürfen Serveränderung und wirksame Client-Behandlung zeitlich auseinanderfallen.
  • Ein belastbarer Nachweis verbindet einen Serverdatensatz mit operationsbezogenen Client-Belegen für Revalidierung, COMMIT und Schreibverifikator.

Ein Verwaltungswert ist noch kein Betriebszustand

Caching gehört zum Leistungsversprechen eines Netzwerkdateisystems. Ein Client hält Daten nahe an der Anwendung und nutzt Protokollregeln, um zu entscheiden, wann er sie erneut verwenden darf. Für manche Dateien ist dieser Tausch ungünstig. Vorhersehbare Sichtbarkeit oder ein klarer Zeitpunkt der Dauerhaftigkeit können wichtiger sein als weniger Netzwerkzugriffe.

Der aktive Entwurf draft-ietf-nfsv4-uncacheable-files-13 ergänzt deshalb ein boolesches Attribut pro Datei. Ein Server oder seine Administration kann damit ausdrücken, dass die üblichen Caching-Vorteile hier nicht gesucht werden. Diese neue Sprache ist nützlich. Sie wird jedoch falsch, wenn eine wahre Serveranzeige im Inventar als „Client-Cache geleert“ erscheint.

Der Serverwert kann den Client nicht von innen beobachten. Der Client muss das Attribut implementieren, die Unterstützung im betreffenden exportierten Dateisystem feststellen, den aktuellen Wert lesen und daraus sein eigenes Verhalten ableiten. Diese Schritte haben unterschiedliche Zeitpunkte. War die Datei beim Wechsel bereits geöffnet, darf der Client sein bisheriges Verhalten zunächst fortsetzen. Über normale Attributabfragen oder Revalidierung lernt er den neuen Wert und wendet ihn auf spätere Operationen an.

Der Zeitpunkt der administrativen Änderung und der Zeitpunkt der Client-Beobachtung sind daher keine konkurrierenden Angaben. Zusammen beschreiben sie die Übertragung einer Vorgabe durch ein zustandsbehaftetes System.

Die Fähigkeit liegt im Export, nicht im Produktnamen

Attribut 87 ist les- und schreibbar und wird in der NFS-Attributtabelle als RECOMMENDED geführt. Dort bezeichnet das Wort eine Attributkategorie. Es verpflichtet nicht jede NFSv4.2-Implementierung zur Unterstützung. Selbst auf einem Server kann die Fähigkeit von einem exportierten Dateisystem zum nächsten wechseln.

Auch der Objekttyp grenzt die Aussage ein. Das Attribut ist für reguläre Dateien und benannte Attribute bestimmt. Bei anderen Typen liefert GETATTR falsch; ein SETATTR auf einem ungeeigneten Typ schlägt fehl. Ein einzelnes „falsch“ unterscheidet deshalb nicht zwischen gewöhnlicher Cachepolitik, fehlender Anwendbarkeit und fehlender Unterstützung. Typ, Unterstützungsmenge und Wert müssen getrennt erfasst werden.

Hinzu kommt die lokale Autorität. Ein Server kann Änderungen zulassen, stets ablehnen oder den Wert aus einer Administrationsregel ableiten, etwa für neu angelegte Dateien unter einem Mountpunkt. Die übliche Autorisierung bleibt bestehen. Ein Prüfdatensatz sollte deshalb Exportidentität, Regelquelle, berechtigte Instanz und abgelehnte Änderungen neben dem Wert aufbewahren.

Diese Trennung verhindert eine verbreitete Fehlmessung: Ein erfolgreicher Test an einem Dateisystem wird nicht versehentlich zur Eigenschaft aller Volumes und Clients desselben Anbieters erklärt.

Dauerhaftigkeit wird am Rücksprung zur Anwendung sichtbar

Auf dem Schreibpfad darf ein Client, der das Attribut beachtet, WRITE nicht allein zum Bündeln oder zur Effizienzsteigerung verzögern. Noch wichtiger ist die Grenze gegenüber der Anwendung. Wenn deren Schreibaufruf erfolgreich zurückkehrt, müssen die Daten auf dem Server dauerhaft sein.

Das kann durch einen stabilen Schreibvorgang geschehen. Ebenso kann der Client zunächst instabil schreiben und COMMIT abschließen, bevor er Erfolg meldet. Ändert sich dabei der Schreibverifikator des Servers, müssen betroffene WRITEs aus den noch verfügbaren Daten wiederholt werden. Die vorübergehende Aufbewahrung für einen laufenden Schreibvorgang gilt im Entwurf nicht als unerlaubtes Caching.

Ein leerer Speicher wäre somit kein sinnvoller Erfolgsbeleg. Er könnte sogar die erforderliche Wiederholung verhindern. Der operationsbezogene Nachweis braucht den angeforderten und bestätigten Stabilitätsmodus, das COMMIT-Ergebnis, den Verifikator vor und nach dem Vorgang, jede Wiederholung und den Zeitpunkt der Erfolgsmeldung an die Anwendung. Erst diese Folge lässt sich nach einem Ausfall gegen eine konkrete Schreiboperation prüfen.

Bei Lesedaten zählt die Grundlage der Wiederverwendung

Für Lesezugriffe verlangt der Entwurf keine demonstrative Totalräumung. Ein Client soll zwischengespeicherte Dateidaten nicht ohne Revalidierung erneut nutzen. Als Mindestprüfung werden das NFS-Änderungsattribut und die Dateigröße genannt. Weitere Merkmale können hinzukommen.

Das setzt den bestehenden Konsistenzansatz von NFSv4.1 fort. Cachegültigkeit hängt nicht bloß von einem Zeitgefühl ab. Sie wird mit Änderungsattribut, Öffnungen, Share Reservations, Sperren und Delegationen koordiniert. Eine Delegation kann dem Client eine konsistente Sicht sichern und damit Lese-Caching auch bei gesetztem neuem Attribut vertretbar machen.

Die Prüffrage lautet folglich nicht, ob eine Speicherseite existierte. Entscheidend ist, welche Protokollgrundlage ihre Nutzung für diese Operation erlaubte. Ein Lesebeleg speichert die verglichenen Änderungswerte und Größen, den Revalidierungszeitpunkt, die einschlägige Delegation oder Sperre sowie die Entscheidung: weiterverwenden, verwerfen, neu laden oder abbrechen.

Zwei Nachweise, eine Verknüpfung

Der Serverdatensatz kann knapp bleiben. Er bezeichnet Server und exportiertes Dateisystem, weist die Unterstützung von Attribut 87 aus, identifiziert Datei, Wert, Richtlinienquelle, Autorität und Beobachtungszeit. Er beantwortet, welche Behandlung der Server zu einem Zeitpunkt angekündigt hat.

Der Clientbeleg identifiziert Implementierung und Version, Mount, Dateihandle und Öffnungsepoche. Er datiert die Beobachtung und hält fest, ob die Datei schon offen war. Bei einem Lesevorgang kommen Änderungswert, Größe, Delegationskontext und Cacheaktion hinzu. Bei einem Schreibvorgang sind es Stabilität, COMMIT, Verifikator, Wiederholung und Rückkehr zur Anwendung.

Beide Datensätze werden über Datei und Operation verbunden, aber nicht zu einem einzigen Wirksamkeitszeitpunkt verdichtet. Eine Änderung um 11 Uhr und eine Client-Beobachtung um 11.09 Uhr sind zwei richtige Ereignisse. Ihre Differenz macht die Verteilung und die verbleibende alte Semantik sichtbar.

Diese Struktur verteilt Verantwortung präzise. Der Server kann richtig konfiguriert sein, während ein alter Client die Funktion nicht versteht. Ein kompatibler Client kann noch unter einer bestehenden Öffnung arbeiten. Ein Fehler kann auch nach korrekter Beobachtung auftreten. Jede Ursache verlangt eine andere Abhilfe.

Freiwillige Einführung als Verteilung zeigen

RFC 8178 beschreibt, wie NFSv4.2 erweitert werden kann, ohne die Basisspezifikation RFC 7862 zu verwerfen. Die neue Funktion ist optional, und Clients behalten innerhalb der festgelegten Invarianten Spielraum bei der Umsetzung. Flottenberichte sollten daher nicht so tun, als sei die jüngste Semantik überall vorhanden.

Sinnvoll sind getrennte Gruppen: Exporte ohne Unterstützung, Unterstützung mit falschem Wert, gesetzter Wert ohne Client-Beobachtung, Anwendung auf neue Operationen und vollständig belegte Operationen. Dieses Bild zeigt die Einführungsgrenze und lenkt Investitionen auf das tatsächliche Hindernis.

Der Implementierungsabschnitt des Entwurfs nennt einen Hammerspace-Serverprototyp und einen Linux-Client, der für Dateien unter einem konfigurierten Mountpunkt ein Direct-I/O-ähnliches Verhalten nutzt. Gemeldete Vorteile bei Leistung, Speicher und CPU für passende Lasten sind ein Hinweis auf Umsetzbarkeit. Sie sind keine Garantie für andere Architekturen oder Lastprofile. Ähnlichkeit ist keine Identität, und ein Prototyp ist kein Flottenstandard.

Keine Sicherheitsgrenze durch Umbenennung

Der Entwurf fügt weder Autorisierung noch Zugriffskontrolle hinzu und untersagt, das Attribut als Grundlage für Sicherheitsentscheidungen zu verwenden. Eine berechtigte Änderung kann Leistung und Datensicht anderer Clients beeinflussen; deshalb ist die Identität des Ändernden prüfenswert. Der Wert wird dadurch aber nicht zum Integritätssiegel oder Beweis, dass alte Daten unmöglich sind.

Öffentliche Aussagen sollten genauso eng bleiben wie die Evidenz. Der Server hat eingeschränktes Caching angefordert. Ein gemessener Client hat den Wert später gesehen. Ein bestimmter Lesevorgang wurde revalidiert. Ein Schreibvorgang war vor der Erfolgsmeldung dauerhaft. Jede Aussage kann belegt werden, aber keine entsteht automatisch aus der ersten.

Der eigentliche Fortschritt ist ausreichend: Das Protokoll erhält ein gemeinsames Feld für eine Serverpräferenz. Ein ergänzender Clientbeleg zeigt, wo daraus Verhalten wurde. Gerade die Trennung macht das neue Signal betrieblich wertvoll.

Quellen