Zusammenfassung

  • Mit dem Abschluss der Wiederherstellung schließt ein Client seine verbleibenden alten Lock-Ansprüche im angegebenen Bereich. Die Erklärung beendet nicht automatisch die Schonfrist anderer Clients.
  • Auch ein bereits fertig gewordener Client kann bei einer neuen Lock-Anfrage noch einen Grace-Fehler erhalten. Seine Fertigmeldung und die Zulassungsentscheidung des Servers betreffen unterschiedliche Verpflichtungen.
  • Nach Netzpartitionen und mehreren Neustarts kann ein alter Anspruch konfliktfrei aussehen, obwohl seine Kontinuität verloren ging. Ohne ausreichende dauerhafte Aufzeichnungen muss der Server konservativ ablehnen.

Ein Neustart, zwei Rückkehrzeiten

Zwei Clients hatten Locks auf einem Dateiserver. Nach einem Neustart hat der Server seinen Lock-Zustand verloren. Ein Client verbindet sich rasch wieder, stellt seine offenen Dateien und Bytebereichssperren wieder her und meldet sich fertig. Der zweite bleibt wegen einer Netzstörung unerreichbar.

Für den ersten Client ist die Wiederherstellung abgeschlossen. Für den Server ist damit eine andere Frage noch offen: Könnte der fehlende Client später einen früheren Lock zurückfordern, mit dem eine jetzt neu gewährte Sperre kollidieren würde? Wer schon zurück ist, kann die Antwort nicht stellvertretend für den Abwesenden geben.

Das ist eine beispielhafte Protokollsituation, kein Bericht über einen beobachteten Ausfall. Die Abschnitte 8.4, 9.11 und 18.51 von RFC 8881 erklären, weshalb NFSv4.1 diese beiden Abschlüsse auseinanderhält. Nach einer erfolgreichen eigenen Abschlussmeldung kann eine neue Lock-Anfrage weiterhin NFS4ERR_GRACE liefern. Darin muss kein Widerspruch liegen.

Wiederherstellen ist keine neue Vergabe

Verliert ein Server Lock-Zustand, braucht er eine Phase, in der Clients frühere Zustände zurückfordern können, ohne von zwischenzeitlich vergebenen kollidierenden Locks verdrängt zu werden. Diese Grace-Phase schützt eine Wiederherstellungschance. Sie ist nicht bloß eine Wartezeit, bis alle Rechner wieder gestartet sind.

Für einen bestehenden offenen Dateizustand verwendet der Client OPEN mit CLAIM_PREVIOUS. Das aktuelle Filehandle bezeichnet dabei die Zieldatei; es handelt sich nicht um das Öffnen eines neuen Namens aus einem Verzeichnis. Bytebereichssperren werden mit LOCK und gesetztem reclaim-Parameter zurückgefordert.

Der Verweis auf früheren Zustand hebt keine Zugriffsprüfung auf. Berechtigungen und echte Konflikte gelten weiter. Ein Client darf während der Wiederherstellung nicht erhalten, was ihm unter entsprechenden normalen Zugriffsbedingungen verwehrt wäre.

Grace bedeutet zugleich keinen pauschalen Stillstand aller Operationen. Client-Identität und Session müssen gerade für die Wiederherstellung eingerichtet werden können. Neue Locks sowie Lese- und Schreibvorgänge können unter den vorgesehenen Bedingungen zugelassen werden, wenn ausreichende Informationen einen Konflikt mit späteren Rückforderungen ausschließen. Wo diese Gewissheit fehlt, beweist eine momentan leere Lock-Tabelle wenig. Die noch nicht eingetroffene Rückforderung ist genau das, was darin nicht steht.

Eine Fertigmeldung mit Verzichtswirkung

Die globale Form von RECLAIM_COMPLETE setzt rca_one_fs auf falsch. Nach dem Aufbau einer neuen Client-ID ist diese Erklärung vor der ersten neuen Lock-Anfrage erforderlich. Das gilt auch für einen Client ohne alte Locks. Dass es für ihn nichts zurückzufordern gibt, muss gegenüber dem Server abgeschlossen werden.

Die Meldung hat eine bindende Wirkung auf den verbliebenen alten Bestand. Nicht wiederhergestellte Locks innerhalb ihres Geltungsbereichs können danach nicht mehr als alte Ansprüche zurückgefordert werden: weder in dieser Wiederherstellungsphase noch in einer späteren Serverinstanz oder nach der betreffenden Übertragung auf einen anderen Server.

Damit ist die Erklärung mehr als ein Fortschrittswert. Sie entfernt mögliche spätere Ansprüche dieses Clients aus der Betrachtung. Der Server darf sich darauf stützen, dass von ihm kein weiterer alter Lock aus diesem Bereich nachgereicht wird.

Die Verzichtswirkung bleibt jedoch beim Erklärenden. Sie überträgt sich nicht auf andere Clients, deren Wiederherstellung noch offen ist. Ein lokaler Abschluss liefert dem Server eine kleinere Menge ungelöster Fälle, nicht automatisch eine leere Menge.

Es gibt außerdem eine dateisystemspezifische Form für Migration. Sie benötigt ein aktuelles Filehandle und ersetzt nicht den globalen Abschluss nach einer neuen Client-ID. Bei einem Dateisystem außerhalb der entsprechenden Migrationssituation sieht die Spezifikation eine erfolgreiche Antwort ohne sonstige Wirkung der Operation vor. Hier geht es um Neustartwiederherstellung; die Migrationsform wird nur genannt, um ihren engeren Bereich nicht mit dem globalen Abschluss zu verwechseln.

Wer fehlt überhaupt?

Um festzustellen, dass alle relevanten Clients fertig sind, muss der Server wissen, welche Clients vorher Locks gehalten haben könnten. Eine dauerhaft gespeicherte Liste macht aus den eintreffenden Erklärungen eine belastbare Vollständigkeitsprüfung. Nur die bereits zurückgekehrten Teilnehmer zu zählen, beantwortet nicht, ob noch jemand fehlt.

Wenn alle möglichen Anspruchsteller abgeschlossen haben, kann eine solche Aufzeichnung ein früheres Ende der Grace-Phase ermöglichen. Der Server kann die Phase auch beenden, bevor jeder Client fertig ist. Daraus folgt aber keine beliebige Verkürzungsbefugnis.

Abschnitt 8.4.2.1 bindet die Wiederherstellungschance an die Lease-Dauer. Er formuliert, dass Grace nicht vor Ablauf dieser Dauer enden sollte, und verlangt im Zusammenhang mit einem geänderten Lease-Wert mindestens die Dauer der vorherigen Instanz. Diese Bedingungen sind kein universeller Sekundenwert für alle Installationen. Sie verlangen, den Zeitrahmen der alten Betriebsbedingungen nicht einfach durch den Neustart zu vergessen.

Für den Betrieb entstehen zwei getrennte Messpunkte: der eigene Abschluss des Clients und die Möglichkeit des Servers, eine konkrete neue Anfrage zuzulassen. Wer den ersten Punkt für den zweiten hält, kann eine erforderliche Schutzmaßnahme als unerklärlichen Wiederherstellungsfehler behandeln.

Der freie Platz erzählt nicht die ganze Geschichte

Besonders heikel ist nicht das Warten selbst, sondern eine alte Besitzvorstellung, die eine tatsächliche Unterbrechung überlebt hat.

RFC 8881 beschreibt einen Client, der wegen einer Netzpartition seine Lease nicht erneuern kann. Sie läuft ab; der Server gibt den Lock frei. Ein anderer Client erhält einen damit unvereinbaren Lock, arbeitet am Objekt und gibt ihn wieder frei. Anschließend startet der Server neu. Die Netzpartition endet, und der erste Client versucht während der neuen Grace-Phase seinen alten Lock zurückzufordern.

Aktuell kann die betreffende Stelle frei sein. Trotzdem kann die Wiederherstellung falsch sein. Falls der andere Client das geschützte Objekt geändert hat, ist die angenommene Kontinuität des ersten längst verloren. Keine gegenwärtige Kollision zu sehen bedeutet nicht, dass die frühere Schutzwirkung ununterbrochen bestanden hat.

Ein zweites beschriebenes Beispiel umfasst zwei Neustarts. Ein Client versäumt, seine Locks während der ersten Grace-Phase vollständig wiederherzustellen. Danach erhält ein anderer einen kollidierenden Lock. Nach einem weiteren Neustart kehrt der erste endlich zurück. Der Beginn einer neuen Grace-Phase darf das Versäumnis der vorherigen nicht aus dem relevanten Verlauf löschen.

Deshalb verlangt die Spezifikation eine von zwei Strategien. Der Server kann alle Rückforderungen mit NFS4ERR_NO_GRACE ablehnen. Oder er muss ausreichend Zustand dauerhaft speichern, um bekannte gefährliche Neustartkonstellationen zu erkennen. Eine vorsichtige Ablehnung ist zulässig, selbst wenn eine vollständigere Kenntnis die Wiederherstellung erlaubt hätte. Bei nicht behebbarer Beschädigung der Aufzeichnungen müssen möglicherweise betroffene Ansprüche zurückgewiesen werden.

Ein im RFC skizzierter Minimaldatensatz enthält beispielsweise Client-Identität sowie Hinweise auf nicht bestätigten Entzug oder unvollständige frühere Wiederherstellung. Das ist kein vorgeschriebenes einheitliches Datenbankschema. Es zeigt, wie der Umfang des gespeicherten Verlaufs mit der Härte späterer Ablehnungen zusammenhängt. Wer wenig unterscheiden kann, darf nicht großzügig so tun, als kenne er den fehlenden Teil.

Die Anwendung muss über die Unterbrechung erfahren können

Ein nach einer Ablehnung neu erworbener Lock beweist nur die neue Gewährung. Er belegt nicht, dass in der Zwischenzeit niemand das Objekt benutzt hat. Gegenwärtige Koordination kann keine vergangene Schutzlücke rückwirkend schließen.

Wie der Client auf NFS4ERR_NO_GRACE reagiert, hängt laut RFC von seiner Betriebsumgebung ab. Das Prüfen des Änderungsattributs eines Objekts und eine mögliche normale Neuöffnung oder Lock-Anfrage werden als ein denkbarer Ansatz unter passenden Bedingungen besprochen. Es ist keine allgemeine Zusicherung, dass jede Anwendung sicher fortfahren kann.

Die offizielle Dokumentseite führt RFC 8881 als Proposed Standard vom August 2020, der RFC 5661 ersetzt. Auch die Errata-Liste wurde geprüft. Bestätigte Korrekturen sind von lediglich gemeldeten Vorschlägen zu unterscheiden. Die abgerufene Liste enthält keine direkte Änderung der drei hier zentralen Abschnitte. Damit sind weder sämtliche Fehler des Dokuments ausgeschlossen noch aktuelle Implementierungen geprüft.

Lu Heng fragt in seiner Note 32 zum Prinzipal-Agent-Problem nach dem Verhältnis von Entscheidungsgewalt und wirtschaftlicher Betroffenheit. Seine Note 36 über Wirklichkeitsbeschreibung statt Interessenwerbung fordert, die Struktur nicht durch Heldengeschichten zu ersetzen. Diese Texte liefern die redaktionelle Perspektive. Die technischen Regeln stammen aus dem RFC; aus ihnen werden hier keine gemessenen Motive eines Anbieters abgeleitet.