Zusammenfassung

  • Der NFSv4-Arbeitsgruppenentwurf vom 26. September ist weiterhin ein aktiver Internet-Draft im Status I-D Exists, kein verabschiedeter RFC.
  • Der neue Abschnitt zu pNFS zeigt, dass die Beseitigung eines veralteten Client-Caches nicht mit einem bereits aktualisierten Metadatenserver gleichzusetzen ist.

Ein Verzeichnislauf für ein Backup kann auf den ersten Blick sauber wirken: Der Client fragt den Server erneut und erhält eine Liste mit Dateigrößen und Zeitstempeln. Eine andere Maschine hat kurz zuvor in eine Datei geschrieben, ohne deren Namen oder Verzeichniseintrag zu ändern. Das Änderungsattribut des Verzeichnisses muss deshalb nicht mitwandern. Der erste Fehlerpfad liegt beim Client, wenn er Attribute einer früheren Auflistung erneut ausgibt. Genau hier setzt das vorgeschlagene boolesche Attribut für nicht zwischenspeicherbare Verzeichniseintrags-Metadaten an.

Bei einem markierten Verzeichnis muss ein Client, der es beachtet, jede Auflistung mit READDIR bedienen und darf für einen Eintrag keine Werte melden, die er schon vor dem zuletzt liefernden READDIR besaß.

Diese Grundidee stand bereits in Fassung 11 vom 5. September. Fassung 12 erklärt genauer, weshalb ein bloßes Signal an den Server nicht genügt. Wer READDIR mit einer knappen Attributanforderung schickt und fehlende Angaben aus dem alten lokalen Cache ergänzt, hat den Beobachtungsfehler nur verlagert. Die nötigen Attribute können mit READDIR angefordert oder anschließend per GETATTR beschafft werden; letzteres kann eine Anfrage je Eintrag kosten. Die Regel betrifft dabei nicht den Dateiinhalt-Cache und erklärt auch nicht sämtliche Verzeichnisse eines Mounts für uncachebar.

Neu ist der Abschnitt 5.2 für Parallel NFS. Das Verzeichnis und sein Attribut stammen vom Metadatenserver, während ein Speichergerät die eigentlichen Daten bereitstellen kann. Bei einem Layout, in dem die geänderte Größe und time_modify erst mit LAYOUTCOMMIT beim Metadatenserver ankommen, liefert ein READDIR davor weiterhin die alten Werte. Meldet der Client diese Werte, hält er die vorgeschlagene Client-Regel ein. Die zeitliche Lücke liegt zwischen dem Datenpfad und der Instanz, die Auskunft über die Einträge gibt. Ein erneuter Abruf kann Wissen nicht vorwegnehmen, das sein Gegenüber noch nicht hat.

Darum ist „frisch“ kein einheitlicher Zustand. Frisch gegenüber einer früheren Client-Auflistung ist etwas anderes als aktuell gegenüber allen Schreibvorgängen in den Speichergeräten. Der Entwurf sagt nicht, dass jedes pNFS-Layout die gleiche LAYOUTCOMMIT-Abfolge nutzt. Er verspricht keine linearisierbare Sicht auf das gesamte Verzeichnis und belegt keinen Vorfall in einer konkreten Installation.

Fassung 12 präzisiert zudem, wer den Schalter überhaupt bedienen darf. Ein Server kann SETATTR für das Verzeichnisattribut nach lokaler Regel verweigern. Dafür muss er NFS4ERR_ACCESS oder, im bezeichneten Eigentümer- beziehungsweise Privilegfall, NFS4ERR_PERM zurückgeben. NFS4ERR_INVAL wäre irreführend: Ein Client, der Unterstützung prüft, würde daraus schließen, der Server kenne das Attribut gar nicht. Technische Unkenntnis und bewusste Verweigerung haben verschiedene Zuständigkeiten und dürfen in Betriebsanzeigen nicht zu einem einzigen Fehler verschmelzen.

Der Datatracker führt den Text als Arbeitsgruppendokument ohne IESG-Abschluss. Ein Hammerspace-Server und ein Linux-Client werden als Prototypen genannt. Daraus folgt weder allgemeine Verfügbarkeit noch ein gemessener Vorteil in produktiven Sicherungssystemen. Die überprüfbare Nachricht ist die schärfere Beschreibung einer begrenzten Regel.

Quellen