Zusammenfassung

  • RFC 9737 lässt einen Client während der Recovery Grace Period mit einem anonymen Null-Stateid I/O-Fehler aus der MDS-Ausfallzeit melden.
  • Ein Fehler kann Resilvering verpflichtend machen; kopiert werden darf jedoch erst nach Fencing, gespeicherter Reparaturabsicht und dem Ende aller ausstehenden Write Intents.
  • Fehlerannahme, Reparaturentscheidung, Ausführungsbefugnis und verifiziertes Dateiergebnis sind vier getrennte Zustände.

Der MDS wusste bereits, dass ein Mirror eine WRITE-Operation abgelehnt hatte. Das Reparaturziel war klar. Trotzdem durfte der Kopiervorgang nicht starten.

Ein anderer Client hielt noch einen Write Intent.

Diese Verzögerung ist kein Implementierungsdetail. Sie schützt die Grenze zwischen einer Entscheidung über inkonsistente Kopien und der Befugnis, diese Kopien zu verändern. Wer beides in einen Status „repair required“ komprimiert, kann eine richtige Diagnose mit einer zu frühen Ausführung verbinden.

Der Bericht überlebt, das alte Layoutrecht nicht

Bei pNFS flexible file layout vergibt der Metadatenserver ein Layout, während Clients direkt auf Data Server zugreifen. Bei clientseitigem Mirroring müssen sie alle Kopien aktualisieren und Fehler melden. ff_ioerr4 trägt Gerät, Operation, Status sowie Byte-Offset und Länge.

Nach einem MDS-Neustart sind alte Layout-Stateids ungültig. Während der Grace Period können Clients Open State mit CLAIM_PREVIOUS zurückfordern, aber sie können kein frisches Layout beschaffen, nur um einen Fehler aus dem alten Kontext zu erzählen.

RFC 9737 verpflichtet den MDS deshalb, im LAYOUTRETURN einen ausschließlich aus Nullen bestehenden anonymen Stateid zu akzeptieren. Das ist keine Wiedererteilung des Layouts. Es ist ein enger Einlass für Recovery-Evidenz.

Innerhalb der Grace Period führt ein anderer Stateid zu NFS4ERR_GRACE; danach führt Null zu NFS4ERR_NO_GRACE. Beim anonymen Return darf der MDS den Seqid des Result-Stateids nicht erhöhen. Der Bericht beeinflusst die Recovery, ohne sich als normale Zustandsfortschreibung auszugeben.

Der Write Intent ist eine eigene operative Schuld

Ein Write Intent entsteht, wenn ein Client LAYOUTIOMODE4_RW erhält. Der MDS muss offene Intents verfolgen und ihre Recovery nach einem Neustart nachhalten. Das ist mehr als Inventar: Der Intent bedeutet, dass ein anderer Akteur die Datei noch verändern könnte.

RFC 9737 beschreibt die grobe Resilvering-Reihenfolge: Datei fencen, Reparaturbedarf dauerhaft vermerken, Write Intent freigeben und erst dann kopieren, wenn kein Intent mehr offen ist. Der MDS darf nicht resilvern, solange Clients ausstehende Schreibabsichten besitzen.

Damit bleibt die Kausalkette sichtbar. Der Fehlerbericht autorisiert die Klassifikation „Reparatur nötig“. Das Fencing und das Ende der Intents autorisieren den Beginn. Die abgeschlossene Kopie und spätere Leseprüfung liefern Ergebnisnachweise. Keine Stufe darf die nächste vorwegnehmen.

Fehlende Evidenz ist kein sauberer Zustand

Wenn ein Client die Datei zurückfordert und keinen Fehler meldet, darf der MDS nicht resilvern. Meldet er einen Fehler, muss der MDS resilvern. Fordert er weder zurück noch meldet er, muss ebenfalls resilvert werden, weil der Client neu gestartet und seine Zustände verloren haben könnte.

Diese drei Fälle schützen vor einem gefährlichen Shortcut. Eine leere Fehlerliste nach aktivem Reclaim ist begrenzte negative Evidenz. Ein ausgebliebener Client ist fehlende Evidenz. Beide als errors=0 zu speichern, beseitigt den Grund für die konservative Reparatur.

Auch der saubere Reclaim beweist keine Byte-Integrität. ff_ioerr4 ist laut RFC 8435 ein Hinweis für den MDS. Nicht beobachtete Beschädigung, andere Clients und Anwendungssemantik bleiben außerhalb des Berichts.

Topologie bindet den Bericht an seinen Mirror-Satz

Der MDS muss das zurückgegebene Layout mit den aktuellen Mirror Instances vergleichen. Stimmen sie nicht überein, muss er den Bericht ignorieren und resilvern. Ein sachlich richtiger Fehler über eine frühere Konfiguration darf die aktuelle Konfiguration nicht steuern.

Deshalb braucht die Beweiskette zwei Mirror-Set-Fingerprints, den Vergleich und den Entscheidungsgrund. Ein Log „error report received“ zeigt nur Transporterfolg. Es sagt nicht, ob der Report als anwendbarer Input akzeptiert wurde.

Operative Prüfung bedeutet hier, reale Mitgliedschaft und reale Uhrzeit über symbolische Gerätenamen zu stellen. Maßgeblich ist der Mirror-Satz, den der laufende MDS tatsächlich rekonstruiert.

Während der Kopie bleibt Gestaltung lokal, Verantwortung nicht

Der MDS kann während des Resilverings sämtliche I/O blockieren, Zugriffe über sich selbst zwingen oder einen Proxy einfügen, der die neue Kopie während des Transfers aktualisiert. Diese Wahl bleibt implementation-specific.

Wenn Zugriff weiter möglich ist, muss der Client dasselbe Layout-Set wie vor dem Neustart sehen. Ein Proxy muss bis zum Ende der Grace Period im Layout bleiben. Die lokale Freiheit ist damit von einer gemeinsamen Konsistenzgrenze umgeben.

Nach dem Start folgen weitere Nachweise: Quell-Mirror lesbar, Bereiche vollständig kopiert, Kopien konvergiert, spätere Reads korrekt, Anwendung zufrieden. Ein angenommener Null-Stateid-Bericht ist kein Abschlussbeleg.

Alte Gegenstellen kaufen Sicherheit mit Aufwand

Ein MDS ohne RFC-9737-Verhalten kann Null mit NFS4ERR_BAD_STATEID ablehnen. Der Client soll dann auf das alte Verhalten zurückfallen und den Fehler auf diesem Weg nicht melden. Es entsteht keine vorgetäuschte Verständigung.

Die Folge ist häufig konservatives Resilvering. Bandbreite, IOPS und Zeit ersetzen eine nicht gemeinsam verstandene Evidenz. Diese Kosten sind vertretbar, müssen aber als Compatibility Debt sichtbar sein.

Für die Freigabe reicht daher kein Funktionsname. Benötigt werden Client- und Server-Version, Recovery-Epoch, Null-Stateid-Versuch, Antwort, Fallback, Mirror-Set-Vergleich, Write-Intent-Zähler, Fencing, Kopierstart und Post-Copy-Prüfung.

RFC 9737 zeigt eine reife Autoritätsordnung: Ein Bericht darf eine Reparatur verlangen, ohne sie sofort starten zu dürfen. Erst wenn konkurrierende Schreibbefugnisse verschwunden sind, wird aus Diagnose Ausführung.

Quellen