Zusammenfassung

  • RFC 3010 trennte den beständigen Clientnamen von der laufenden Inkarnation: Ein nach Neustart wechselnder Verifier, der ausgehandelte clientid und eine authentisierte Bestätigung verhinderten, dass Namensgleichheit alte Sperren erbt.
  • Nach Zustandsverlust des Servers erhielten Reclaims ungefähr eine Lease-Dauer lang Vorrang; neue potenziell kollidierende Sperren und E/A warteten. Kontinuität war ein befristetes Verfahren, kein ewiges Recht.

Der neu gestartete Server konnte die Datei lesen, aber nicht mehr sagen, wer sie exklusiv benutzen durfte. Beim Client lag noch ein stateid, beim Server nur eine leere flüchtige Tabelle. Würde jetzt die erste neue Anfrage gewinnen, entschiede die Geschwindigkeit nach dem Ausfall über einen früheren Anspruch.

RFC 3010 veröffentlichte im Dezember 2000 die erste vollständige NFSv4-Spezifikation. Mit integriertem Locking musste NFS nicht nur Zustand führen, sondern auch erklären, wie dessen Autorität über Absturz, Neustart und Partition hinweg geprüft oder beendet wird.

Zunächst unterschied das Protokoll Client und Clientinkarnation. Der Client sendete eine länger stabile opaque ID und einen Verifier, der sich nach jeder Initialisierung ändern sollte. Ein Rechnername beantwortet „welches System?“, aber nicht „welcher Start?“. Nur die zweite Frage passte zur Lebensdauer des flüchtigen Sperrzustands.

SETCLIENTID band die Angaben an den authentisierten RPC-Principal. Der Server gab einen kurzen clientid und einen Bestätigungsverifier zurück; SETCLIENTID_CONFIRM schloss die Aushandlung. Der clientid war danach eine effiziente lokale Referenz. Er war weder globale Identität noch Eigentumstitel oder übertragbares Berechtigungsobjekt.

Auch gleiche Namen mussten nicht dieselbe Partei bedeuten. Geklonte Hochverfügbarkeitskonfigurationen oder Fehler konnten zwei Clients dieselbe opaque ID geben. NFS4ERR_CLID_INUSE machte den Zusammenstoß sichtbar. Gleichheit war ein Anlass zur Trennung, nicht zur stillen Vereinigung ihrer Rechte.

Kam derselbe authentisierte Principal mit neuem Verifier zurück, durfte der Server eine neue Inkarnation und den Verlust früherer Client-Erinnerung annehmen. Er konnte die alten Locks freigeben. Ohne Bindung an den Principal wäre der Verifier gefährlich: Ein Fremder könnte einen Neustart vortäuschen und fremde Sperren löschen.

Die zweite Grenze war die Lease. Der Server bestimmte eine gemeinsame Laufzeit für den Zustand eines Clients. Normale zustandsbezogene Operationen erneuerten sie implizit; ein inaktiver Client konnte RENEW senden. Eine Erneuerung umfasste alle Sperren, weshalb die Kontrolllast nicht mit ihrer Anzahl wuchs.

Nach Ablauf durfte der Server Zustand zurücknehmen und Konflikte gewähren. Kehrte ein Client nach langer Partition mit altem stateid zurück, konnte NFS4ERR_EXPIRED folgen. Das zwang ihn, den Verlust der Exklusivität an die Anwendung zu melden. Lokale Erinnerung hielt den Server nicht unbegrenzt gebunden.

Beim Serverneustart lag die Erinnerung auf der anderen Seite. Der Client kannte clientid und stateid, der Server jedoch nicht mehr deren Epoche. NFS4ERR_STALE_CLIENTID und NFS4ERR_STALE_STATEID markierten den Bruch. Danach musste ein neuer clientid entstehen und die Wiederherstellung beginnen.

Die Grace Period regelte die Reihenfolge. Etwa eine Lease lang konnten frühere Clients LOCK und OPEN als Reclaim, einschließlich CLAIM_PREVIOUS, einreichen. Die einfache sichere Reaktion auf neue Locks, Opens, Reads und Writes war NFS4ERR_GRACE. Der Server antwortete, hielt aber seine Macht über neue Konflikte vorübergehend zurück.

Diese Absage schützte noch abwesende frühere Inhaber. Sie brauchten Zeit, um den Neustart zu bemerken und ihre Zustandsliste aufzubauen. Ohne Grace würde die Ankunftsreihenfolge nach einem Fehler zum Vergabeverfahren. Durch das Ende des Fensters erhielt ein toter Client zugleich kein unbefristetes Vetorecht.

Mit stabil gespeicherten Belegen durfte der Server selektiver handeln. Er musste garantieren können, dass keine spätere Rückforderung kollidiert oder wegen des neuen Vorgangs scheitert. Persistente Lock-Aufzeichnungen konnten die gesperrte Fläche verkleinern. Verfügbarkeit beruhte dann auf erhaltenem Wissen, nicht auf Optimismus.

Ein verspäteter Reclaim außerhalb des Fensters durfte nur Erfolg haben, wenn seit dem Neustart keine kollidierende Sperre oder E/A gewährt worden war. Nach neuen Tatsachen konnte ein ungespeicherter alter Anspruch nicht risikolos rückwirkend herrschen. Die Frist begrenzte deshalb den Preis der Ungewissheit.

RFC 2624 beschrieb die Entwurfsziele. RFC 3010 wurde durch RFC 3530 ersetzt; RFC 7530 ist eine spätere NFSv4.0-Spezifikation. Diese Geschichte darf nicht als heutige Implementierungsanleitung gelesen werden.

In NFSv4.1 ergänzte RFC 5661 EXCHANGE_ID, Sessions und genauere Wiederherstellung. Der Nachfolger RFC 8881 verdeutlicht den Tausch: Je großzügiger Reclaims nach schwierigen Ausfällen anerkannt werden sollen, desto mehr Client- und Zustandswissen muss dauerhaft verwahrt sein.

Unter Lu Hengs Running-Code Primacy entsteht das wirksame Recht erst aus lokal ausführbaren Prüfungen: Principal, Inkarnation, Lease, Reclaim-Form, Fenster und fehlender späterer Konflikt. Die gemeinsame Mindestregel verhindert, dass ein Neuankömmling allein wegen schnellerer Ankunft nach einem Fehler gewinnt.

Die Stability Fallacy läge darin, gleichen Namen oder erreichbaren Export mit unveränderter Autorität gleichzusetzen. RFC 3010 zeigte den Verlust als stale, hielt Konflikte kurz zurück und ließ die Belegkette neu entstehen. Nicht die Erinnerung des Clients rettete die Sperre. Das Protokoll erinnerte sich daran, in welcher Reihenfolge Vergessen verarbeitet werden musste.

Sources