Zusammenfassung

  • Der vom IESG gebilligte NFSv4.2-Entwurf definiert ein Boolesches Attribut pro Datei, das unterstützende Clients zur Begrenzung langlebiger Datencaches anhält; die Implementierung ist nicht für jeden Server verpflichtend und das Attribut bleibt beratend.
  • true beweist weder eine Umstellung bestehender OPENs noch den COMMIT eines instabilen WRITE, die Sichtbarkeit von pNFS-Metadaten oder die Beobachtung der Bytes durch eine andere Anwendung.

Ein Server kann künftig im Protokoll ausdrücken, dass eine bestimmte Datei für gewöhnliches clientseitiges Daten-Caching ungeeignet ist. Für HPC-Lasten und gemeinsam beschriebene Dateien entsteht damit eine einheitliche Alternative dazu, jede Anwendung für ein O_DIRECT-ähnliches lokales Verhalten umzubauen.

Die Erklärung leert aber keinen Cache.

Am 17. September billigte das IESG Adding an Uncacheable File Data Attribute to NFSv4.2 und übergab das Dokument an die RFC-Editor-Warteschlange. Revision 16 definiert fattr4_uncacheable_file_data, Attribut 87, als les- und schreibbaren Booleschen Wert für reguläre Dateien und benannte Attribute. RECOMMENDED bezeichnet dabei eine NFS-Attributklasse; es verpflichtet nicht jeden Server zur Unterstützung.

Die Unterstützung gilt je exportiertem Dateisystem. Zwei Exporte desselben Servers dürfen sich unterscheiden. Ein Client prüft supported_attrs oder testet die Funktion. Ein nicht unterstütztes SETATTR scheitert mit NFS4ERR_ATTRNOTSUPP, während GETATTR das Feld lediglich auslässt. Fehlende Ausgabe braucht also Kontext.

Beachtet ein Client den wahren Wert, darf er WRITE-Daten nicht allein zum Zusammenfassen mehrerer Vorgänge oder zur Effizienzsteigerung zurückhalten. Die Regel begrenzt ein konkretes Risiko: Zwei Clients können getrennte Bereiche desselben Blocks ändern, worauf einer eine veraltete Kopie über die Aktualisierung des anderen schreibt. Frühe Übertragung verkleinert dieses Write-Hole-Fenster.

Dauerhaftigkeit hat eine eigene Beweiskette. Das Attribut legt stable_how4 nicht fest. Stattdessen verlangt der Entwurf, dass Daten beim erfolgreichen Rückkehrpunkt des Anwendungsaufrufs auf dem Server dauerhaft sind. FILE_SYNC4 oder DATA_SYNC4 können das mit der WRITE-Antwort erreichen. Bei UNSTABLE4 muss COMMIT vorher enden. Ändert sich der Write Verifier, sind betroffene WRITEs erneut aus dem noch verfügbaren Anwendungspuffer zu senden.

Diese kurzzeitige Aufbewahrung zur Abwicklung eines instabilen WRITE ist nicht der langlebige Cache, den das Attribut einschränkt. Umgekehrt ersetzt der gesetzte Wert keinen fehlenden COMMIT. „Nicht cachebar“ ist eine Richtlinie für Datenkopien, kein Beleg bereits erreichter Persistenz.

Lesesichtbarkeit bringt weitere Bedingungen. Hält ein Client gelesene Daten, sollte er sie erst nach erneuter Prüfung des Change-Attributs und der Dateigröße verwenden. Eine Delegation kann auf anderem Weg eine konsistente Sicht liefern. Bei pNFS kommt das Attribut vom Metadatenserver, während Daten direkt zu Speichergeräten fließen können. Dauerhafte Bytes dort und sichtbare Layout-Metadaten sind getrennte Ereignisse. Wo LAYOUTCOMMIT erforderlich ist, kann eine Verzögerung andere Clients noch gegen ältere Metadaten prüfen lassen.

Auch die Zeitachse widerlegt eine Ein-Bit-Erzählung. Ändert sich das Attribut während einer offenen Datei, darf der Client die beim OPEN gewählte Cache-Entscheidung bis zum Ende dieses Opens beibehalten. Ablauf des Attribut-Caches, erneute Prüfung und spätere OPENs begrenzen die Verzögerung. Das heutige true beschreibt nicht automatisch jede gestrige Öffnung.

Das Feld erhält auch keine Sicherheitsbefugnis. Bestehende Serverrichtlinien und Autorisierung bestimmen, wer es setzen oder löschen darf. Der Entwurf fügt keine Authentifizierung hinzu, ändert keine Zugriffskontrolle und schafft keine Sicherheitsgrenze. Vorhandene Konsistenz- und Integritätsmechanismen behalten ihre Aufgaben.

Revision 16 nennt einen Hammerspace-Serverprototyp und einen Linux-Clientprototyp sowie beobachtete Vorteile bei wohlgeformter Ein-/Ausgabe. Das belegt Ausführbarkeit, nicht breite Einführung, Standardaktivierung, produktübergreifende Interoperabilität oder allgemeinen Leistungsgewinn. Entscheidend bleibt die Beobachtung, ob ein konkreter Client folgt und was sich im Workload tatsächlich ändert.

Ein belastbares Betriebsprotokoll verbindet deshalb Spezifikationsrevision, Exportunterstützung, Serverrichtlinie, den von einem benannten Client gesehenen Wert, OPEN-Zeitpunkt, Implementierung und Version, WRITE-Stabilität, Verifier und COMMIT, gegebenenfalls LAYOUTCOMMIT, Leserevalidierung und Anwendungsergebnis. Der Boolesche Wert eröffnet die Beweiskette; er schließt sie nicht.

Quellen