Zusammenfassung

  • Mit LAYOUT_WCC kann ein pNFS-Client die nach einer NFSv3-Operation empfangenen Attribute eines Datenfiles an den Metadatenserver melden.
  • Der Server darf dadurch auf GETATTR verzichten, die Meldung ignorieren oder unmittelbar nachprüfen; eine Quittung über einzelne übernommene Attribute gibt es nicht.
  • Gemeldete Größe und Zeitwerte beweisen weder stabile Bytes noch den Gleichstand aller Spiegel oder das Ergebnis auf Anwendungsebene.

Bei verteiltem Speicher ist dieselbe Frage nicht für jeden Beteiligten gleich teuer. Der Client hat gerade mit dem Datenserver gesprochen und dessen Antwort vorliegen. Der Metadatenserver soll kurz darauf die Dateigröße nennen, war aber beim Schreibvorgang nicht beteiligt. Er kann den Datenserver noch einmal fragen. RFC 9766 erlaubt stattdessen, die vorhandene Beobachtung weiterzureichen.

Entscheidend ist nicht nur der eingesparte Weg, sondern die Zuständigkeit für Zweifel. Der Client liefert eine Aussage aus einem bestimmten Vorgang. Der Metadatenserver entscheidet, ob Alter, Konfliktlage und Folgen eine neue Messung verlangen. So wird Effizienz möglich, ohne die Hoheit über Metadaten an den Überbringer zu verlagern.

Direkter Datenzugriff hat eine Wissenslücke

pNFS teilt einen Dateidienst in getrennte Verantwortungsflächen. Der Metadatenserver verwaltet Namensraum und Metadaten, vergibt und widerruft Layouts und kann E/A selbst bedienen. Ein Layout kann den Client zugleich zu Datenservern führen. Beim flexible file layout dürfen diese mit vorhandenen NFS-Versionen arbeiten, auch mit NFSv3.

Der direkte Weg entlastet den Metadatenserver von Teilen des Datenverkehrs. Zugleich sieht er nicht jede Veränderung. Ein Client mit Lese-/Schreib-Layout kann ein Datenfile verlängern, ohne dass der Metadatenserver an der Operation teilnimmt. NFSv3 kennt keine allgemeine Rückmeldung, mit der der Datenserver anschließend jede Änderung an ihn meldet. Die Bytes ändern sich an einer Stelle, die Auskunftspflicht bleibt an einer anderen.

Der Metadatenserver kann die Lücke mit GETATTR schließen. Er fragt den Datenserver nach aktuellen Attributen und vergleicht etwa Größe, Platzverbrauch oder Zeitwerte. Das ist ein stärkerer Messweg, kostet aber eine weitere Operation. Bei vielen Metadatenabfragen wandert so erhebliche Prüflast auf die Speicherebene. Außerdem benötigen ein NFSv3-WRITE und das folgende GETATTR zwei Hin- und Rückwege, wo NFSv4 bestimmte Arbeit in einer Compound-Operation bündeln kann.

RFC 9766 definiert NFSv4.2-Operation 77, LAYOUT_WCC. Antworten auf NFSv3-READ, WRITE und COMMIT können Weak-Cache-Consistency-Daten enthalten. Der Client bildet diese Werte auf NFSv4.2-Attribute ab und meldet sie dem Metadatenserver.

Schwach bezeichnet den Beweiswert

WCC nach RFC 1813 verbindet ausgewählte Attribute vor einer Operation mit Attributen danach. Der Vergleich kann zeigen, dass möglicherweise eine weitere Änderung stattgefunden hat und gecachte Daten verworfen werden sollten. Er erzählt mehr als nur ein abschließender Schnappschuss.

Strikte Kohärenz entsteht daraus nicht. Für das stärkste Ergebnis müssten Vorzustand, verändernde Operation und Nachzustand atomar behandelt werden. Greift ein anderer Akteur in dieses Beobachtungsfenster ein, kann Information verloren gehen. Auch ein korrektes Ergebnis sperrt keinen späteren Schreiber aus.

RFC 9766 lässt diese Schwäche sichtbar. Der Metadatenserver darf die Meldung für hinreichend frisch halten und eine Sonde einsparen. Bei alten Werten, Widerspruch oder hoher Tragweite darf er trotzdem GETATTR ausführen. Der Standard setzt die gemeinsame Sprache; die Risikogrenze bleibt eine lokale Entscheidung.

Beide Seiten besitzen Ermessensspielraum. Ein Client darf empfangene WCC-Informationen ungenutzt lassen. Ein Server darf gemeldete Attribute ignorieren. Weil der Client gegen das Ignorieren nichts unternehmen muss, enthält die Antwort keine Bitmap der akzeptierten Felder. Ein erfolgreicher Aufruf belegt daher nicht, dass jeder Wert in den maßgeblichen Metadatenzustand übernommen wurde.

Acht Felder, aber kein automatischer Befund

Für das flexible file layout werden acht NFSv3-Attribute abgebildet: size, space_used, mode, owner, owner_group, time_access, time_modify und time_metadata. Numerische uid- und gid-Werte werden zu den Zeichenketten für Eigentümer und Gruppe in NFSv4.

Die Gruppe umfasst Kapazität, Zeit und zugriffsnahe Information. Eine größere Datei passt zu einem Schreibvorgang, beweist dessen Ursache jedoch nicht allein. Ein jüngerer Zugriffszeitpunkt passt zu einem Lesevorgang, nennt aber keinen Verbraucher. Eine Abweichung bei Eigentümer oder Modus kann einen Zugriffsfehler erklären helfen, sagt jedoch nicht, welche Seite falsch liegt.

Der RFC nennt Situationen, in denen die Meldung nützlich sein kann. Der Client kann sie vor einer Anfrage nach Größe, Platzverbrauch, Change-Attribut oder Zeitwerten schicken. Bei NFS4ERR_ACCESS kann er beobachtete uid/gid-Werte beilegen. Unter geeigneter Delegation kann er sie bei der Aktualisierung von Zugriffs- und Änderungszeiten melden.

Das sind Diagnosepunkte, keine Reparaturbefehle. Ein Eigentümerkonflikt kann aus veralteten Daten auf dem Datenserver, einer überholten Erwartung des Metadatenservers oder einem nicht mehr gültigen Layout stammen. Würde die bloße Abweichung SETATTR auslösen, bekäme eine Beobachtung unverdient Schreibmacht.

Listenpositionen sind keine Objektkennungen

Der aktuelle Filehandle und lowa_stateid binden die Meldung an ein Layout; lowa_type legt fest, wie die opake Nutzlast zu lesen ist. Beim flexible file layout kann sie Spiegel und deren Datenserver beschreiben.

Ihre Reihenfolge ist keine dauerhafte Identität. Bei drei Spiegeln kann ein Client alle aufführen und dem unveränderten Spiegel eine leere Attributmaske geben. Er darf auch nur die zwei veränderten senden. Dann bezeichnet die zweite Position etwas anderes. Ein Datenfile muss deshalb über device ID, stateid und Filehandle identifiziert werden. Alle drei sind nötig, weil ein Layout mehrere Datenfiles auf demselben Gerät unterbringen kann.

Die allgemeine Evidenzregel lautet: Nachbarschaft ersetzt keinen Namen. Eine Quittung, die Auslassung und Umsortierung überstehen soll, braucht für jedes beobachtete Objekt stabile Identitätsfelder.

Auch Fehler sind nicht immer vollständig atomar. Bei einem zulässigen Fehler kann der Metadatenserver die gesamte Operation verwerfen oder – sofern die layoutspezifische Nutzlast es erlaubt – einen Teil anwenden. Ein bloßer RPC-Status kann diese Teilentscheidung nicht rekonstruieren. Ein brauchbares Audit hält Dateiidentität, Maske, Werte und Anwendungsergebnis fest.

Attribute, Persistenz, Spiegel und Anwendung

Gemeldete Größe und Änderungszeit sind der erste Belegtyp. Die stabile Ablage der Daten ist ein anderer. Liefert ein Schreibvorgang nicht FILE_SYNC, verlangt das flexible file layout, instabile Writes vor LAYOUTCOMMIT durch COMMIT stabil zu machen. LAYOUT_WCC ersetzt weder diesen Schritt noch dessen Quittung.

Ein dritter Beleg betrifft die Spiegel. Beim clientseitigen Mirroring macht RFC 8435 den Client für die Aktualisierung aller Kopien verantwortlich. Eine Schreibtransaktion gilt nur dann als erfolgreich, wenn sämtliche Kopien aktualisiert wurden. Ein Fehler kann dem Metadatenserver Reparaturbedarf anzeigen. Die Attribute eines einzelnen Datenfiles sagen jedoch nichts Verlässliches über unbeobachtete Kopien.

Der vierte Beleg liegt oberhalb des Dateisystems. Der Server kann die richtige Größe kennen, während eine Anwendung alte Bytes aus einem eigenen Cache liest. Sämtliche Kopien können übereinstimmen, obwohl die Anwendung den falschen Namen geöffnet hat. Beobachtung, Dauerhaftigkeit, Replikation und fachliches Ergebnis dürfen nicht in einer grünen Anzeige zusammenfallen.

Optionalität schützt unabhängige Entwicklung

LAYOUT_WCC ist für NFSv4.2 und für das flexible file layout optional. Clients und Server ohne Operation 77 können über bestehende Wege interoperabel bleiben, darunter die direkte Attributabfrage. Ihr Aufwand kann höher sein; das Fehlen der Optimierung ist für sich kein Funktionsfehler.

RFC 8178 regelt NFSv4-Erweiterungen, RFC 7862 und RFC 7863 liefern Protokoll- und XDR-Grundlage für NFSv4.2. Diese Dokumente belegen Syntax und Standardstatus. Ob konkrete Endpunkte Unterstützung ausgehandelt und den Mechanismus ausgeführt haben, kann nur die laufende Umgebung zeigen.

Das Sicherheitsmodell stammt aus dem flexible file layout. Lose Kopplung kann synthetische uid/gid-Werte nutzen, um kooperative Clients einzugrenzen, schützt aber nicht zwingend gegen bösartige Clients und kann nicht immer einen einzelnen Client abtrennen. Enge Kopplung hängt von ihrem Kontrollprotokoll ab. Backend-Kommunikation muss gegen Mitlesen und Manipulation geschützt werden. Eine authentifizierte Meldung belegt ihren Absender im Kanal; sie beweist nicht, dass jeder Wert noch den jüngsten Zustand des Datenservers darstellt.

Quellen

  1. RFC 9766: Extensions for Weak Cache Consistency in NFSv4.2's Flexible File Layout
  2. RFC 8435: Parallel NFS Flexible File Layout
  3. RFC 8434: Requirements for pNFS Layout Types
  4. RFC 1813: NFS Version 3 Protocol
  5. RFC 8881: NFS Version 4 Minor Version 1 Protocol
  6. RFC 7862: NFS Version 4 Minor Version 2 Protocol
  7. RFC 7863: NFSv4.2 XDR Description
  8. RFC 8178: Rules for NFSv4 Extensions and Minor Versions
  9. RFC 9754: Extensions for Opening and Delegating Files in NFSv4.2
  10. Running-Code Primacy
  11. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  12. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile