Optionen, die von allen Versionen unterstützt werden

Diese Optionen sind für die Verwendung mit allen NFS-Versionen gültig.

nfsvers=n

Die NFS-Protokollnummer, die für den Kontakt zum NFS-Dienst des Servers verwandt wird. Falls der Server die angefragte Version nicht unterstützt, schlägt die Einhängeanfrage fehl. Falls diese Option nicht angegeben ist, versucht der Client 4.2 zuerst, handelt sich dann runter, bis er eine vom Server unterstützte Version findet.

vers=n

Diese Option ist eine Alternative zu der Option nfsvers. Sie ist für die Kompatibilität zu anderen Betriebssystemen enthalten.

soft / softerr / hard

Bestimmt das Wiederherstellungsverhalten des NFS-Clients nachdem es zu einer Zeitüberschreitung für eine NFS-Anfrage kam. Falls keine Option angegeben ist (oder falls die Option hard angegeben ist), werden NFS-Anfragen unendlich oft erneut versucht. Falls entweder die Option soft oder softerr angegeben ist, lässt der NFS-Client eine NFS-Anfrage nach retrans Übertragungsversuchen fehlschlagen. Dadurch liefert der NFS-Client den Fehler EIO (für die Option soft) oder ETIMEDOUT (für die Option softerr) an die aufrufende Anwendung zurück.

Nebenbemerkung: Eine sogenannte »weiche« Zeitüberschreitung kann in bestimmten Fällen zu stiller Datenverfälschung führen. Verwenden Sie daher die Option soft oder softerr nur, wenn die Reaktionsfähigkeit des Clients wichtiger als die Datenintegrität ist. Die Verwendung von NFS über TCP oder die Erhöhung des Wertes der Option retrans kann einige der Risiken des Einsatzes der Option soft oder softerr verringern.

softreval / nosoftreval

Falls der NFS-Server nicht verfügbar ist, könnte es nützlich sein, dass NFS-Clients Pfade und Attribute weiterhin aus dem Zwischenspeicher bereitstellen, nachdem retrans Versuche, den Zwischenspeicher erneut zu bestätigen, wegen Zeitüberschreitungen fehlschlugen. Dies könnte beispielsweise hilfreich sein, wenn versucht wird, einen Dateisystembaum von einem Server, der permanent nicht verfügbar ist, auszuhängen.

Es ist möglich, softreval mit der Einhängeoption soft zu kombinieren. In diesem Fall erfolgt eine Zeitüberschreitung für Aktionen, die nicht aus dem Zwischenspeicher bedient werden können, sowie ein Fehler nach retrans Versuchen. Die Kombination mit der Vorgabeeinhängeoption hard impliziert, dass Aktionen, die nicht im Zwischenspeicher liegen, zu Wiederholungen führen, bis vom Server eine Antwort erhalten wird.

Hinweis: Die Vorgabeeinhängeoption ist nosoftreval. Diese erlaubt keinen Rückgriff auf den Zwischenspeicher, wenn die Neubestätigung fehlschlägt, sondern folgt stattdessen dem durch die Einhängeoptionen hard oder soft vorgegebenen Verhalten.

intr/nointr

Diese Aktion wird für Rückwärtskompatibilität bereitgestellt. Sie wird nach Kernel 2.6.25 ignoriert.

timeo=n

Die Zeit in Zehntelsekunden, die der NFS-Client auf eine Antwort wartet, bevor er eine NFS-Anfrage erneut versucht.

Für NFS über TCP beträgt der Standardwert für timeo 600 (60 Sekunden). Der NFS-Client führt einen linearen Rückschritt aus: Nach jeder Neuübertragung wird die Zeitüberschreitung um timeo bis zum Maximum von 600 Sekunden erhöht.

Für NFS über UDP verwendet der Client einen adaptiven Algorithmus, um die angemessenen Werte für eine Zeitüberschreitung (Timeput) für häufig verwandte Anfragetypen (wie READ- und WRITE-Anfragen) abzuschätzen, verwendet allerdings die Einstellung timeo für seltenere Anfragetypen (wie FSINFO-Anfragen). Falls die Option timeo nicht angegeben ist, werden solche selten verwandten Anfragetypen nach 1,1 Sekunden erneut versucht. Nach jeder Neuübertragung verdoppelt der NFS-Client die Zeitüberschreitung für diese Anfrage bis zu einem maximalen Wert für die Zeitüberschreitung von 60 Sekunden.

retrans=n

Die Anzahl der Versuche, die der NFS-Client eine Anfrage erneut unternimmt, bevor er weitere Wiederherstellungsmaßnahmen einleitet. Falls die Option retrans nicht angegeben ist, versucht der NFS-Client jede UDF-Anfrage drei Mal und jede TCP-Anfrage zweimal.

Der NFS-Client erzeugt »server not responding« (Server reagiert nicht) Nachrichten nach retrans Versuchen. Dann versucht er weitere Wiederherstellungen (abhängig davon, ob die Einhängeoption hard in Kraft ist).

rsize=n

Die maximale Anzahl von Bytes, die der NFS-Client beim Lesen von Daten aus einer Datei auf einem NFS-Server in jeder Netz-READ-Anfrage empfangen kann. Die tatsächliche Datenmenge jeder NFS-READ-Anfrage ist identisch zu oder kleiner als die Einstellung von rsize. Die größte von dem Linux-NFS-Client unterstützte Lese-Datenmenge ist 1.048.576 Bytes (ein Megabyte).

Der Wert von rsize ist ein positives, ganzzahliges Vielfaches von 1024. Werte von rsize kleiner als 1024 werden durch 4096 ersetzt; Werte größer als 1048576 durch 1048576. Falls ein angegebener Wert in den unterstützten Bereich fällt, aber kein Vielfaches von 1024 ist, wird er auf das nächste Vielfache von 1024 abgerundet.

Falls der Wert rsize nicht angegeben ist oder falls der angegebene Wert für rsize größer als das maximale sowohl vom Server oder vom Client unterstützte ist, handeln der Client und der Server den größten Wert für rsize aus, den beide unterstützen.

Die Einhängeoption rsize taucht in der Datei /etc/mtab so auf, wie sie auf der mount(8)-Befehlszeile angegeben wurde. Der effektive zwischen Server und Client ausgehandelte Wert von rsize wird allerdings in der Datei /proc/mounts angezeigt.

wsize=n

Die maximale Anzahl von Bytes, die der NFS-Client beim Schreiben von Daten in eine Datei auf einem NFS-Server in jeder Netz-WRITE-Anfrage senden kann. Die tatsächliche Datenmenge jeder NFS-WRITE-Anfrage ist identisch zu oder kleiner als die Einstellung von wsize. Die größte von dem Linux-NFS-Client unterstützte Schreibe-Datenmenge ist 1.048.576 Bytes (ein Megabyte).

Ähnlich wie rsize ist der Wert von wsize ein positives, ganzzahliges Vielfaches von 1024. Werte von wsize kleiner als 1024 werden durch 4096 ersetzt; Werte größer als 1048576 durch 1048576. Falls ein angegebener Wert in den unterstützten Bereich fällt, aber kein Vielfaches von 1024 ist, wird er auf das nächste Vielfache von 1024 abgerundet.

Falls ein Wert von wsize nicht angegeben ist oder der angegebene Wert von wsize größer als das maximal vom Client oder Server unterstützbare ist, werden der Client und Server den größten Wert von wsize aushandeln, den beide unterstützen können.

Die Einhängeoption wsize taucht in der Datei /etc/mtab so auf, wie sie auf der mount(8)-Befehlszeile angegeben wurde. Der effektive zwischen Server und Client ausgehandelte Wert von wsize wird allerdings in der Datei /proc/mounts angezeigt.

ac/noac

Wählt aus, ob der Client Dateiattribute zwischenspeichern darf. Falls keine Option angegeben ist (oder falls ac angegeben ist), speichert der Client Dateiattribute zwischen.

Um die Leistung zu erhöhen, speichern NFS-Clients Dateiattribute zwischen. Alle paar Sekunden prüft ein NFS-Client die Version des Servers von jedem Dateiattribut auf Aktualisierungen. Änderungen, die auf dem Server innerhalb dieser kurzen Intervalle passieren, bleiben unerkannt, bis der Server durch den Client erneut geprüft wird. Die Option noac verhindert, dass Clients Dateiattribute zwischenspeichern, so dass Anwendungen schneller Dateiänderungen auf dem Server erkennen können.

Zusätzlich zur Verhinderung des Zwischenspeicherns von Dateiattributen durch den Client zwingt die Option noac Anwendungen dazu, Schreibvorgänge synchron durchzuführen, so dass lokale Änderungen an einer Datei auf dem Server sofort sichtbar werden. Damit können andere Clients schnell neue Schreibvorgänge erkennen, wenn sie die Dateiattribute überprüfen.

Die Verwendung der Option noac stellt größere Kohärenz der Zwischenspeicher unter NFS-Clients, die auf die gleiche Datei zugreifen, sicher, führt aber zu einem großen Leistungseinbruch. Stattdessen wird eine gezieltere Verwendung von Dateisperren empfohlen. Der Abschnitt DATEN- UND METADATENKOHÄRENZ enthält eine detaillierte Diskussion dieses Zielkonflikts.

acregmin=n

Die minimale Zeit in Sekunden, die Attribute einer regulären Datei vom NFS-Client zwischengespeichert, bevor frische Informationen vom Server angefordert werden sollen. Falls diese Option nicht angegeben ist, verwendet der NFS-Client ein Minimum von 3 Sekunden. Siehe den Abschnitt DATEN- UND METADATENKOHÄRENZ für eine komplette Besprechung des Zwischenspeicherns von Attributen.

acregmax=n

Die maximale Zeit in Sekunden, die Attribute einer regulären Datei vom NFS-Client zwischengespeichert, bevor frische Informationen vom Server angefordert werden sollen. Falls diese Option nicht angegeben ist, verwendet der NFS-Client ein Maximum von 60 Sekunden. Siehe den Abschnitt DATEN- UND METADATENKOHÄRENZ für eine komplette Besprechung des Zwischenspeicherns von Attributen.

acdirmin=n

Die minimale Zeit in Sekunden, die Attribute eines Verzeichnisses vom NFS-Client zwischengespeichert, bevor frische Informationen vom Server angefordert werden sollen. Falls diese Option nicht angegeben ist, verwendet der NFS-Client ein Minimum von 30 Sekunden. Siehe den Abschnitt DATEN- UND METADATENKOHÄRENZ für eine komplette Besprechung des Zwischenspeicherns von Attributen.

acdirmax=n

Die maximale Zeit in Sekunden, die Attribute eines Verzeichnisses vom NFS-Client zwischengespeichert, bevor frische Informationen vom Server angefordert werden sollen. Falls diese Option nicht angegeben ist, verwendet der NFS-Client ein Maximum von 60 Sekunden. Siehe den Abschnitt DATEN- UND METADATENKOHÄRENZ für eine komplette Besprechung des Zwischenspeicherns von Attributen.

actimeo=n

Die Angabe von actimeo setzt die Größen acregmin, acregmax, acdirmin und acdirmax auf den gleichen Wert. Falls diese Option nicht angegeben ist verwendet der NFS-Client die oben aufgeführten Vorgaben für jede dieser Optionen.

bg/fg

Bestimmt, wie sich der Befehl mount(8) verhält, falls ein Versuch des Einhängens eines exportierten Verzeichnisses fehlschlägt. Die Option fg führt dazu, dass mount(8) sich mit einem Fehlerstatus beendet, falls irgend ein Teil der Einhängeanfrage in eine Zeitüberschreitung läuft oder fehlschlägt. Dies wird »Vordergrund«-Einhängung genannt und ist das Standardverhalten, falls weder die Einhängeoption fg noch bg angegeben ist.

Falls die Option bg angegeben ist, wird eine Zeitüberschreitung oder ein Fehlschlag dazu führen, dass der Befehl mount(8) mit Fork einen Kindprozess startet, der weiter versucht, das exportierte Dateisystem einzuhängen. Der Elternprozess kommt sofort mit einem Exit-Code von Null zurück. Dies ist als »Hintergrund«-Einhängung bekannt.

Falls das lokale Einhängeverzeichnis fehlt, verhält sich der Befehl mount(8), als ob eine Zeitüberschreitung aufgetreten wäre. Dies erlaubt in /etc/fstab angegebene verschachtelte NFS-Einhängungen in beliebiger Reihenfolge während des Systemstarts fortzufahren, selbst falls einige NFS-Server noch nicht verfügbar sind. Alternativ können diese Probleme mit einem Selbsteinhängeprogramm angegangen werden (siehe automount(8) für Details).

nconnect=n

Beim Einsatz eines verbindungsorientierten Protokolls wie TCP kann es manchmal von Vorteil sein, mehrere Verbindungen zwischen Client und Server einzurichten. Falls beispielsweise Ihre Clients und/oder Server mit mehreren Netzwerkschnittstellenkarten (NICs) ausgerüstet sind, können mehrere Verbindungen zur Lastverteilung die Gesamtleistung erhöhen. In diesen Fällen erlaubt die Option nconnect dem Benutzer die Angabe der Verbindungsanzahl, die zwischen dem Client und dem Server aufgebaut werden sollen (bis zur Begrenzung von 16).

Beachten Sie, dass die Option nconnect auch bei einigen pNFS-Laufwerken zur Angabe der Anzahl der einzurichtenden Verbindungen zu den Daten-Servern verwandt werden kann.

rdirplus/nordirplus

Wählt aus, ob NFS-v3- oder -v4-READDIRPLUS-Anfragen verwandt werden sollen. Falls diese Option nicht angegeben ist, verwendet der NFS-Client READDIRPLUS-Anfragen auf NFS-v3- oder -v4-Einhängungen, um kleine Verzeichnisse zu lesen. Einige Anwendungen arbeiten besser, falls der Client nur READDIR-Anfragen für alle Verzeichnisse verwendet.

retry=n

Die Anzahl an Minuten, die der Befehl mount(8) versucht, eine NFS-Einhängungsaktion im Vordergrund oder im Hintergrund durchzuführen, bevor er aufgibt. Falls diese Option nicht angegeben ist, ist der Standardwert für Vordergrundeinhängungen 2 Minuten und für Hintergrundeinhängungen 10000 Minuten (80 Minuten weniger als eine Woche). Falls ein Wert von 0 angegeben ist, wird der Befehl mount(8) sich sofort nach dem ersten Fehler beenden.

Beachten Sie, dass dies nur die Anzahl der durchgeführten Versuche beeinflusst, nicht die durch jeden Versuch hervorgerufene Verzögerung. Für UDP benötigt jeder Versuch die durch die Optionen timeo und retrans bestimmte Zeit, die standardmäßig 7 Sekunden ist. Für TCP ist die Vorgabe 3 Minuten, aber System-TCP-Verbindungszeitüberschreitungen begrenzen manchmal die Zeitüberschreitung für jede Neuübertragung auf rund 2 Minuten.

sec=Varianten

Eine durch Doppelpunkt getrennte Liste von einem oder mehreren Sicherheitsvarianten, die beim Zugriff auf Dateien auf dem eingehängten Export verwandt werden sollen. Falls der Server keine dieser Varianten unterstützt, schlägt die Einhängeaktion fehl. Falls sec= nicht angegeben ist, versucht der Client eine Sicherheitsvariante zu finden, die sowohl vom Client als auch vom Server unterstützt wird. Gültige Varianten sind none, sys, krb5, krb5i und krb5p. Der Abschnitt SICHERHEITSBETRACHTUNGEN enthält Details.

sharecache/nosharecache

Bestimmt, wie die Daten- und Attributszwischenspeicher des Clients gemeinsam benutzt werden, wenn die exportierten Verzeichnisse gleichzeitig mehr als einmal eingehängt werden. Die Verwendung des gleichen Zwischenspeichers reduziert die Speicheranforderungen auf dem Client und präsentiert Anwendungen identische Dateiinhalte, wenn auf die gleiche Datei aus der Ferne über verschiedene Einhängepunkte aus zugegriffen wird.

Falls keine der Optionen oder falls die Option sharecache angegeben ist, wird ein einzelner Zwischenspeicher für alle Einhängepunkte, die auf den gleichen Export zugreifen, verwandt. Falls die Option nosharecache angegeben ist, dann bekommt dieser Einhängepunkt einen separaten Zwischenspeicher. Beachten Sie, dass die Einhängeoptionen von dem ersten Einhängepunkt auch für folgende gleichzeitige Einhängungen auf dem gleichen Export verwendet werden, falls die Daten- und Attributzwischenspeicher gemeinsam benutzt werden.

Ab Kernel 2.6.18 ist das mit nosharecache angegebene Verhalten veraltet. Es wird als Datenrisiko betrachtet, da mehrere zwischengespeicherte Kopien der gleichen Datei auf dem gleichen Client nach einer lokalen Aktualisierung einer der Kopien auseinanderlaufen können.

resvport/noresvport

Gibt an, ob der NFS-Client einen privilegierten Quell-Port für die Kommunikation mit dem NFS-Server für diesen Einhängepunkt verwenden soll. Falls diese Option nicht oder die Option resvport angegeben ist, verwendet der NFS-Client einen privilegierten Quell-Port. Falls die Option noresvport angegeben ist, verwendet der NFS-Client einen nichtprivilegierten Port. Diese Option wird durch Kernel 2.6.28 und neuer unterstützt.

Die Verwendung von nichtprivilegierten Quell-Ports hilft bei der Erhöhung der auf dem Client maximal erlaubten Anzahl an NFS-Einhängepunkten. Allerdings muss der NFS-Server so konfiguriert sein, dass er Clients erlaubt, sich über nichtprivilegierte Quell-Ports zu verbinden.

Der Abschnitt SICHERHEITSBETRACHTUNGEN enthält wichtige Details.

lookupcache=Modus

Gibt an, wie der Kernel seinen Zwischenspeicher von Verzeichniseinträgen für einen angegebenen Einhängepunkt verwaltet. Modus kann entweder all, none, pos oder positive sein. Diese Option wird durch Kernel 2.6.28 und neuer unterstützt.

Der Linux-NFS-Client speichert die Ergebnisse aller »NFS LOOKUP«-Anfragen zwischen. Falls der angeforderte Verzeichniseintrag auf dem Server existiert, wird auf das Ergebnis als positive referenziert. Falls der angeforderte Verzeichniseintrag auf dem Server nicht existiert, wird auf das Ergebnis als negative referenziert.

Falls diese Option nicht oder all angegeben ist, nimmt der Client an, dass beide Arten von Verzeichniseinträgen gültig sind, bis die zwischengespeicherten Attribute des Elternverzeichnisses verfallen.

Falls pos oder positive angegeben ist, nimmt der Client an, dass positive Einträge gültig sind, bis die zwischengespeicherten Attribute des Elternverzeichnisses verfallen, überprüft aber immer negative Einträge, bevor eine Anwendung sie verwenden kann.

Falls none angegeben ist, überprüft der Client beide Arten von Verzeichniszwischenspeichereinträgen, bevor eine Anwendung sie verwenden kann. Dies ermöglicht eine schnelle Erkennung von Dateien, die von anderen Clients angelegt oder entfernt wurden, kann aber Auswirkungen auf Anwendungen und die Leistung des Servers haben.

Der Abschnitt DATEN- UND METADATENKOHÄRENZ enthält eine detaillierte Diskussion dieses Zielkonflikts.

fsc/nofsc

aktiviert/deaktiviert das Zwischenspeichern von (nur lesbaren) Datenseiten auf der lokalen Platte mittels der FS-Cache-Einrichtung. Siehe cachefilesd(8) und <kernel_source>/Documentation/filesystems/caching für Details zur Einrichtung der FS-Cache-Einrichtung. Die Vorgabe ist nofsc.

sloppy

Die Option sloppy ist eine Alternative zur Angabe der Option »-s« von mount.nfs.

xprtsec=Richtlinie

Legt die Verwendung der Transportebenenabsicherung fest, um den NFS-Netzwerkverkehr im Auftrag dieses Einhängepunktes abzusichern. Richtlinie kann entweder none, tls oder mtls sein.

Falls none angegeben ist, wird die Transportebenensicherheit zwangsweise ausgeschaltet, selbst falls der NFS-Server Transportebenensicherheit unterstützt.

Falls tls angegeben ist, verwendet der Client RPC-mit-TLS, um Vertrauenswürdigkeit während der Übertragung sicherzustellen.

Falls mtls angegeben ist, verwendet der Client RPC-mit-TLS, um sich zu authentifizieren und Vertrauenswürdigkeit während der Übertragung sicherzustellen.

Falls entweder tls oder mtls angegeben ist und der Server RPC-mit-TLS nicht unterstützt oder die Authentifizierung unter Gleichrangingen fehlschlägt, schlägt der Einhängeversuch fehl.

Falls die Option xprtsec= nicht festgelegt wurde, hängt das Standardverhalten von der Kernelversion ab, ist aber normalerweise zu xprtsec=none äquivalent.

Optionen nur für NFS-Version 2 und 3

Verwenden Sie diese Optionen, zusammen mit den Optionen in den obigen Unterabschnitten, nur für NFS Version 2 und 3.

proto=NetID

Die NetID bestimmt den Transport, der zur Kommunikation mit dem NFS-Server verwandt wird. Verfügbare Optionen sind udp, udp6, tcp, tcp6, rdma und rdma6. Die in 6 endenden verwenden IPv6-Adressen und sind nur bei eingebauter Unterstützung für TI-RPC verfügbar. Die anderen verwenden IPv4-Adressen.

Jedes Transportprotokoll verwendet andere Vorgaben für die Einstellungen von retrans und timeo. Lesen Sie die Beschreibungen dieser Einhängeoptionen für Details.

Diese Einhängungsoption steuert, wie der NFS-Client Anfragen an den Server überträgt und zusätzlich, wie der Befehl mount(8) auch mit den Diensten Rpcbind und Mountd des Servers kommuniziert. Wird eine Netid angegeben, die TCP verwendet, wird aller Verkehr von dem Befehl mount(8) und dem NFS-Client dazu gezwungen, TCP zu verwenden. Wird eine Netid angegeben, die UDP verwendet, werden alle Verkehrstypen zur Verwendung von UDP gezwungen.

Lesen Sie den Abschnitt TRANSPORTMETHODEN unten, bevor Sie NFS über UDP verwenden.

Falls die Einhängeoption proto nicht angegeben ist, findet der Befehl mount(8) heraus, welche Protokolle der Server unterstützt und wählt für jeden Dienst ein angemessenes Protokoll. Lesen Sie den Abschnitt TRANSPORTMETHODEN für weitere Details.

udp

Die Option udp ist eine Alternative zur Angabe von proto=udp. Sie ist zur Kompatibilität mit anderen Betriebssystemen enthalten.

Lesen Sie den Abschnitt TRANSPORTMETHODEN unten, bevor Sie NFS über UDP verwenden.

tcp

Die Option tcp ist eine Alternative zur Angabe von proto=tcp. Sie ist zur Kompatibilität mit anderen Betriebssystemen enthalten.

rdma

Die Option rdma ist eine Alternative zur Angabe von proto=rdma.

port=n

Der numerische Wert des Dienste-Ports des NFS-Servers. Falls der NFS-Dienst des Servers nicht auf dem Port verfügbar ist, schlägt die Einhängeanfrage fehl.

Falls diese Option nicht angegeben ist oder falls der angegebene Port-Wert 0 ist, wird der NFS-Client die vom Rpcbind-Dienst des Servers bekanntgemachte Server-Port-Nummer verwenden. Die Einhängeanfrage schlägt fehl, falls der Rpcbind-Dienst des Servers nicht verfügbar ist, der NFS-Dienst nicht beim Rpcbind-Dienst des Servers registriert ist oder falls der NFS-Dienst des Servers nicht auf dem bekanntgemachten Port des Servers verfügbar ist.

mountport=n

Der numerische Wert des Mountd-Ports des Servers. Falls der Mountd-Dienst des Servers nicht auf dem Port verfügbar ist, schlägt die Einhängeanfrage fehl.

Falls diese Option nicht angegeben ist oder falls der angegebene Port-Wert 0 ist, wird der Befehl mount(8) die vom Rpcbind-Dienst des Servers bekanntgemachte Mountd-Dienstenummer verwenden. Die Einhängeanfrage schlägt fehl, falls der Rpcbind-Dienst des Servers nicht verfügbar ist, der Mountd-Dienst nicht beim Rpcbind-Dienst des Servers registriert ist oder falls der Mountd-Dienst des Servers nicht auf dem bekanntgemachten Port des Servers verfügbar ist.

Diese Option kann bei Einhängen eines NFS-Servers durch eine Firewall, die das Rpcbind-Protokoll blockiert, verwandt werden.

mountproto=netid

Den Transport, den der NFS-Client verwendet, um Anfragen an den Mountd-Dienst des Servers zu übertragen, wenn er diese Einhängeanfrage durchführt und später, wenn der diesen Einhängepunkt aushängt.

netid kann entweder udp oder tcp sein, die IPv4-Adressen verwenden, oder, falls TI-RPC im Befehl mount.nfs eingebaut ist, udp6 oder tcp6, die IPv6-Adressen verwenden.

Diese Option kann beim Einhängen eines NFS-Servers durch eine Firewall, die bestimmte Transporte blockiert, verwendet werden. Falls es in Kombination mit der Option proto verwandt wird, können verschiedene Transporte für Mountd-Anfragen und für NFS-Anfragen angegeben werden. Falls der Mountd-Dienst des Server über den angegebenen Transport nicht verfügbar ist, schlägt die Einhängeanfrage fehl.

Lesen Sie den Abschnitt TRANSPORTMETHODEN für Informationen, wie die Einhängeoption mountproto mit der Einhängeoption proto wechselwirkt.

mounthost=Name

Der Rechnername des Rechners, der Mountd betreibt. Falls diese Option nicht angegeben ist, nimmt der Befehl mount(8) an, dass der Dienst Mountd auf dem gleichen Rechner wie der NFS-Dienst läuft.

mountvers=n

Die für den Kontakt zum Mountd des Servers zu verwendende PRC-Versionsnummer. Falls diese Option nicht angegeben ist, verwendet der Client eine der gewünschten NFS-Version angemessene Versionsnummer. Diese Option ist nützlich, falls mehrere NFS-Dienste auf dem selben Rechner in der Ferne laufen.

namlen=n

Die maximale Länge der Pfadnamenkomponente bei dieser Einhängung. Falls diese Option nicht angegeben ist, wird die maximale Länge mit dem Server ausgehandelt. Meistens ist die maximale Länge 255 Zeichen.

Einige ältere Versionen von NFS unterstützten diese Aushandlung nicht. Mittels dieser Option wird sichergestellt, dass pathconf(3) in diesen Fällen die geeignete maximale Komponentenlänge an Anwendungen meldet.

lock/nolock

Wählt aus, ob das NLM-Seitenbandprotokoll zum Sperren von Dateien auf dem Server verwandt wird. Falls keine der Optionen (oder lock) angegeben ist, wird NLM-Sperrung für diesen Einhängepunkt verwandt. Beim Verwenden der Option nolock können Anwendungen Dateien sperren, aber diese Sperren stellen einen exklusiven Zugriff nur gegenüber anderen Anwendungen auf dem gleichen Client sicher. Anwendungen in der Ferne sind von diesen Sperren nicht betroffen.

Das Sperren mit NLM muss mit der Option nolock deaktiviert sein, wenn NFS zum Einhängen von /var verwandt wird, da /var Dateien enthält, die von der NLM-Implementierung von Linux verwandt werden. Die Verwendung der Option nolock ist auch notwendig, wenn Exporte auf NFS-Servern eingehängt werden, die das NLM-Protokoll nicht unterstützen.

cto/nocto

Wählt aus, ob die »close-to-open« (Schließen-bis-Öffnen) Zwischenspeicherkohärenzsemantik verwandt wird. Falls keine Option (oder falls cto) angegeben ist, verwendet der Client »close-to-open«-Zwischenspeicherkohärenzsemantik. Falls die Option nocto angegeben ist, verwendet der Client eine nicht standardisierte Heuristik, um zu bestimmen, wann sich Dateien auf dem Server geändert haben.

Der Einsatz der Option nocto kann die Leistung für rein-lesbare Einhängungen erhöhen. Er sollte aber nur verwandt werden, wenn sich die Daten auf dem Server nur gelegentlich ändern. Der Abschnitt DATEN- UND METADATENKOHÄRENZ enthält eine detailliertere Diskussion des Verhaltens dieser Option.

acl/noacl

Wählt aus, ob bei diesem Einhängepunkt das NFSACL-Seitenbandprotokoll verwandt werden soll. Das NFSACL-Seitenbandprotokoll ist ein in Solaris implementiertes proprietäres Protokoll, das Zugriffssteuerlisten verwaltet. NFSACL wurde nie zu einem Standardteil der NFS-Protokollspezifikation.

Falls weder die Option acl noch noacl angegeben ist, handelt der NFS-Client mit dem Server aus, ob das NFSACL-Protokoll unterstützt wird und verwendet es, falls der Server es unterstützt. Falls die Aushandlung zu Problemen auf dem Client oder Server führt, könnte die Deaktivierung des NFSACL-Seitenbandprotokolls notwendig sein. Der Abschnitt SICHERHEITSBETRACHTUNGEN enthält weitere Details.

local_lock=Mechanismus

Gibt an, ob lokale Sperren für einen oder beide der Sperrmechanismen (Flock und POSIX) verwandt werden sollen. Mechanismus kann entweder all, flock, posix oder none sein. Diese Option wird seit Kernel 2.6.37 unterstützt.

Der Linux-NFS-Client bietet eine Möglichkeit, Sperren lokal durchzuführen. Das bedeutet, dass Anwendungen Dateien sperren können. Allerdings bieten solche Sperren nur Ausschlussrechte gegenüber anderen Anwendungen, die auf dem gleichen Client laufen. Anwendungen auf anderen Rechnern sind von diesen Sperren nicht betroffen.

Falls diese Option nicht oder falls none angegeben ist, nimmt der Client an, dass die Sperren nicht lokal sind.

Falls all angegeben ist, nimmt der Client an, dass sowohl Flock- als auch POSIX-Sperren lokal sind.

Falls flock angegeben ist, nimmt der Client an, dass nur Flock-Sperren lokal sind und verwendet das NLM-Sideband-Protokoll, wenn POSIX-Sperren verwandt werden.

Falls posix angegeben ist, nimmt der Client an, dass POSIX-Sperren lokal sind und verwendet das NLM-Sideband-Protokoll, wenn Flock-Sperren verwandt werden.

Um herkömmliches Flock-Verhalten zu unterstützen, das dem von NFS-Clients < 2.6.12 ähnlich ist, benutzen Sie »local_lock=flock«. Diese Option wird benötigt, wenn NFS-Einhängungen über Samba exportiert werden, da Samba Windows-Freigabemodusspeerren als Flock exportiert. Da NFS-Clients > 2.6.12 Flock durch Emulieren von POSIX-Sperren implementieren, wird dies zu im Konflikt stehenden Sperren führen.

Hinweis: Falls sie zusammen verwandt werden, wird die Einhängeoption »local_lock« durch die Einhängeoption »nolock«/»lock« außer Kraft gesetzt.

Optionen nur für NFS-Version 4

Verwenden Sie diese Optionen zusammen mit den Optionen in dem ersten obigen Unterabschnitt für NFS-Version 4 oder neuer.

proto=NetID

netid bestimmt den Transport, der für die Kommunikation mit dem NFS-Server verwandt wird. Unterstützte Optionen sind tcp, tcp6, rdma und rdma6. tcp6 verwendet IPv6-Adressen und ist nur verfügbar, falls Unterstützung für TI-RPC eingebaut ist. Die beiden anderen verwenden IPv4-Adressen.

Alle NFS-Version-4-Server müssen TCP unterstützen. Daher verwendet der NFS-Version-4-Client das TCP-Protokoll, falls diese Option nicht angegeben ist. Lesen Sie den Abschnitt TRANSPORTMETHODEN für weitere Details.

minorversion=n

Gibt die Unterversionsnummer des Protokolls an. NFSv4 führt »Unterversionen« ein, bei denen NFS-Protokollerweiterungen ohne Erhöhung der NFS-Protokollversionsnummer eingeführt werden können. Vor Kernel 2.6.38 war die Unterversionsnummer immer Null und diese Option wird nicht erkannt. Nach diesem Kernel aktiviert die Angabe von »minorversion=1« eine Reihe von fortschrittlichen Funktionalitäten, wie NFSv4-Sitzungen.

Neuere Kernel erlauben die Angabe der Unterversionsnummer mittels der Option vers=. Beispielsweise ist die Angabe vers=4.1 identisch zur Angabe vers=4,minorversion=1.

port=n

Der numerische Wert des Dienste-Ports des NFS-Servers. Falls der NFS-Dienst des Servers nicht auf dem Port verfügbar ist, schlägt die Einhängeanfrage fehl.

Falls diese Einhängeoption nicht angegeben ist, verwendet der NFS-Client die Standard-Portnummer 2049, ohne erst den Rpcbind-Dienst des Servers zu prüfen. Dies erlaubt es, einem NFS-Version-4-Client, Kontakt zu einem Server aufzunehmen, der hinter einer Firewall, die Rpcbind-Anfragen blockiert, liegt.

Falls der angegebene Port-Wert 0 ist, verwendet der NFS-Client die vom Rpcbind-Dienst des NFS-Servers bekanntgegebene Port-Nummer. Die Einhängeanfrage schlägt fehl, falls der Rpcbind-Dienst des Servers nicht verfügbar, der NFS-Dienst nicht in dem Rpcbind-Dienst registriert oder der NFS-Dienst auf dem bekanntgegebenen Port nicht verfügbar ist.

cto/nocto

Wählt aus, ob für diesen Einhängepunkt »close-to-open«-Zwischenspeicherkohärenzsemantik für NFS-Verzeichnisse verwandt wird. Falls weder cto noch nocto angegeben sind, ist die Vorgabe, »close-to-open«-Zwischenspeicherkohärenzsemantik für Verzeichnisse zu verwenden.

Das Zwischenspeichern von Dateidaten wird durch diese Option nicht beeinflusst. Der Abschnitt DATEN- UND METADATENKOHÄRENZ enthält eine detailliertere Beschreibung dieser Option.

clientaddr=n.n.n.n

clientaddr=n:n:…:n

Gibt eine einzelne IPv4-Adresse (in Dreipunktschreibweise) oder eine Nicht-Link-Local-IPv6-Adresse, die der NFS-Client bekanntgibt, um Servern zu erlauben, NFS-Version-4-Rückrufanfrage für Dateien auf diesem Einhängepunkt durchzuführen, an. Falls der Server keine Rückrufverbindungen zu Clients aufbauen kann, kann sich die Leistung verringern oder Dateizugriffe können zeitweise hängen. Ein Wert von IPv4_ANY (0.0.0.0) oder äquivalente IP6-any-Adresse kann angegeben werden. Damit wird dem NFS-Server signalisiert, dass dieser NFS-Client keine Delegationen möchte.

Falls diese Option nicht angegeben ist, versucht der Befehl mount(8) die geeigneten Rückrufadressen automatisch zu ermitteln. Dieser automatische Ermittlungsprozess ist allerdings nicht perfekt. Falls mehrere Client-Netzschnittstellen, spezielle Routing-Optionen oder atypische Netztopologien vorhanden sind, ist es möglicherweise nicht trivial, die genaue Adresse für Rückrufe zu ermitteln.

NFS-Protokollversionen 4.1 und 4.2 verwenden Client-etablierte TCP-Verbindungen für Rückrufanfragen und benötigen daher nicht, dass sich der Server mit dem Client verbindet. Diese Option betrifft daher nur NFS-Version-4.0-Einhängungen.

migration/nomigration

Wählt aus, ob der Client eine Identifizierungszeichenkette verwendet, die mit dem »NFSv4 Transparent State Migration (TSM)« kompatibel ist. Falls der eingehängte Server NFSv4-Migration mit TSM unterstützt, geben Sie die Option migration an.

Einige Server-Funktionalitäten funktionieren im Angesicht einer Migrations-kompatiblen Identifizierungszeichenkette nicht richtig. Die Option nomigration erhält die Verwendung einer traditionellen Client-Identifizierungszeichenkette, die mit veralteten NFS-Servern kompatibel ist. Dies ist auch das Verhalten, falls keine der Optionen angegeben wurde. Die offenen und Sperrenstatus können nicht transparent migriert werden, wenn er sich selbst mit einer traditionellen Identifizierungszeichenkette identifiziert.

Diese Einhängeoption hat bei NFSv4-Versionen, deren Unternummer größer als Null ist, keinen Effekt. Bei diesen wird immer eine TSM-kompatible Identifizierungszeichenkette verwandt.

max_connect=n

Während nconnect eine Begrenzung für die Anzahl der Verbindungen setzt, die mit einer angegeben Server-IP etabliert werden können, erlaubt die Option max_connect dem Benutzer, die maximale Anzahl an Verbindungen an verschiedene Server-IPs, die zum gleichen NFSv4.1+-Server gehören (Sitzungs-Trunk-Verbindungen), bis zu einer Schranke von 16 festzulegen. Wenn ein Client ermittelt, dass es eine Client-Kennung zu einem bereits bestehenden Server etabliert, wird der Client diese Verbindung zu der Liste der verfügbaren Transporte für diesen RPC-Client hinzufügen, statt den neu erstellten Netzwerktransport zu verwerfen.

trunkdiscovery / notrunkdiscovery

Wenn der Client ein neues Dateisystem auf einem NFSv4.1+-Server entdeckt, wird die Einhängeoption trunkdiscovery ihn dazu veranlassen, ein GETATTR für das Attribut fs_locations zu senden. Falls er eine Antwort erhält, deren Länge nicht Null ist, wird er durch die Antwort durchlaufen und für jeden Serverort eine Verbindung etablieren, eine EXCHANGE_ID senden und auf Sitzungsbündelung prüfen. Falls der Bündelungstest erfolgreich ist, wird die Verbindung zu der bestehenden Gruppe an Transporten für den Server hinzugefügt, abhängig von der in der Option max_connect festgelegten Begrenzung. Die Vorgabe ist notrunkdiscovery.

Verwendung der Einhängeoption »mountproto«

Dieser Abschnitt betrifft nur NFS-Version-3-Einhängungen, da NFS Version 4 kein separates Protokoll für Einhängeanfragen verwendet.

Der Linux-NFS-Client kann verschiedene Transporte zum Verbindungsaufbau mit einem Rpcbind-Dienst, einem Mountd-Dienst, dem »Network Lock Manager«- (NLM)-Dienst und dem NFS-Dienst des NFS-Servers verwenden. Der genaue durch den Linux-NFS-Client eingesetzte Transport hängt von den Einstellungen der Transporteinhängeoptionen ab, zu denen proto, mountproto, udp und tcp gehören.

Der Client schickt »Network Status Manager (NSM)«-Benachrichtigungen über UDP unabhängig davon, welche Transportoptionen angegeben wurden, wartet aber auf die NSM-Benachrichtigungen des Servers sowohl auf UDP als auch TCP. Das Protokoll »NFS Access Control List (NFSACL)« nutzt den gleichen Transport wie der Haupt-NFS-Dienst.

Falls keine Transportoptionen angegeben wurden, verwendet der Linux-NFS-Client standardmäßig UDP, um den Mountd-Dienst des Servers zu kontaktieren und TCP, um seine NLM- und NFS-Dienste zu kontaktieren.

Falls der Server diese Transporte für diese Dienste nicht unterstützt, versucht der Befehl mount(8) herauszufinden, was der Server unterstützt und versucht dann, die Einhängeanfrage erneut mit den herausgefundenen Transporten. Falls der Server keine vom Client unterstützten Transporte bekanntgibt, schlägt die Einhängeanfrage fehl. Falls die Option bg benutzt wird, bringt sich der Einhängebefehl in den Hintergrund und versucht die angegebene Einhängeanfragen weiter.

Wenn die Option proto, die Option udp oder die Option tcp aber nicht die Option mountproto angegeben ist, wird der angegebene Transport sowohl für den Kontakt zum Mountd-Dienst des Servers als auch für die NLM- und NFS-Dienste benutzt.

Falls die Option mountproto aber keine der Optionen proto, udp oder tcp angegeben sind, wird der angegebene Transport für die initiale Mountd-Anfrage verwandt, der Befehl mount versucht aber zu ermitteln, was der Server für das NFS-Protokoll unterstützt. Dabei bevorzugt er TCP, falls beide Transporte unterstützt werden.

Falls beide Option mountproto und proto (oder udp oder tcp) angegeben sind dann wird der mit der Option mountproto angegebene Transport für die anfängliche Mountd-Anfrage und der mit der Option proto (oder den Optionen udp oder tcp) angegebene Transport für NFS verwandt, unabhängig von der Reihenfolge der Optionen. Falls diese Optionen angegeben sind, erfolgt keine automatische Erkennung der Dienste.

Falls eine der Optionen proto, udp, tcp oder mountproto mehr als einmal auf der gleichen Befehlszeile angegeben werden, dann tritt der Wert, der am weitesten rechts steht, in Kraft.

Verwendung von NFS über UDP auf Hochgeschwindigkeitsverbindungen

Die Verwendung von NFS über UDP auf Hochgeschwindigkeitsverbindungen wie Gigabit kann ohne Rückmeldung zu Datenverfälschung führen.

Das Problem kann durch hohe Lasten ausgelöst werden und wird durch Probleme in dem IP-Fragment-Wiederzusammenbau verursacht. NFS-Lese- und Schreibvorgänge übertragen typischerweise UDP-Pakete von 4 Kilobyte oder mehr, die in mehrere Fragmente zerteilt werden müssen, damit sie über eine Ethernet-Verbindung übertragen werden können, da diese standardmäßig Pakete auf 1500 byte begrenzt. Dieser Prozess passiert in der IP-Netzschicht und wird Fragmentierung genannt.

Um zusammengehörige Fragmente zu identifizieren, weist IP jedem Paket einen 16-bit-IP ID-Wert zu. Fragmente, die vom gleichen UDP-Paket erstellt wurden, werden die gleiche IP-Kennung haben. Das Empfangssystem sammelt dann diese Fragmente und kombiniert sie so, dass daraus das ursprüngliche UDP-Paket entsteht. Dieser Prozess heißt Wiederzusammenbau. Die Standardzeitüberschreitung für den Paketwiederzusammenbau ist 30 Sekunden. Falls der Netzwerkstapel nicht alle Fragmente für ein bestimmtes Paket innerhalb dieses Intervalls erhält, nimmt er an, dass fehlende Fragmente verloren gegangen sind und verwirft die bereits empfangenen.

Dies erzeugt bei Hochgeschwindigkeitsverbindungen ein Problem, da es möglich ist, mehr als 65536 Pakete innerhalb von 30 Sekunden zu übertragen. Tatsächlich kann bei umfangreichem NFS-Verkehr beobachtet werden, dass sich die IP-Kennungen nach rund 5 Sekunden wiederholen.

Das hat ernsthafte Effekte für den Wiederzusammenbau: Falls ein Fragment verloren geht und ein anderes Fragment von einem anderen Paket mit der gleichen IP-Kennung innerhalb der 30-Sekunden-Zeitüberschreitung eintrifft wird der Netzwerkstapel diese Fragmente zu einem neuen Paket zusammensetzen. Meistens werden Netzschichten oberhalb von IP diesen fehlerhaften Wiederzusammenbau erkennen. Im Falle von UDP wird die UDP-Prüfsumme, eine 16-Bit-Prüfsumme, normalerweise nicht korrekt sein und UDP wird das defekte Paket verwerfen.

Allerdings ist die UDP-Prüfsumme nur 16 Bit, so dass es eine Möglichkeit von 1 in 65536 gibt, dass die Prüfsumme passt, obwohl der Nutzinhalt vollkommen zufällig ist (was allerdings sehr oft nicht der Fall ist). Trifft dies zu, dann sind Daten ohne Rückmeldung defekt.

Diese Möglichkeit sollte sehr ernst genommen werden, zumindest auf Gigabit-Ethernet. Netzgeschwindigkeiten von 100 MBit/s sollten als weniger problematisch betrachtet werden, da bei den meisten Verkehrsmustern der Umlauf der IP-Kennung sehr viel länger als 30 Sekunden betragen wird.

Es wird daher nachdrücklich empfohlen, wo möglich NFS über TCP zu verwenden, da TCP keine Fragmentierung durchführt.

Wenn Sie unbedingt NFS über UDP über Gigabit-Ethernet verwenden müssen, können ein paar Dinge unternommen werden, um dem Problem entgegen zu wirken und die Wahrscheinlichkeit für Verfälschungen zu reduzieren:

Jumbo Frames:

Viele Gigabit-Netzkarten sind in der Lage, Frames größer als die Begrenzung des traditionellen Ethernet von 1500 byte zu übertragen, typischerweise 9000 bytes. Werden Jumbo Frames von 9000 bytes verwandt, kann NFS über UDP mit Seitengrößen von 8 K ohne Fragmentierung betrieben werden. Natürlich ist das nur möglich, falls alle beteiligten Stationen Jumbo Frames unterstützen.

Um einer Maschine auf Karten, die das unterstützen, zu ermöglichen, Jumbo Frames zu versenden, reicht es aus, die Schnittstelle für einen MTU-Wert von 9000 zu konfigurieren.

Niederigere Zeitüberschreitung für den Wiederzusammenbau:

Durch Absenken dieser Zeitüberschreitung unter die Zeit, die für den IP-Kennungszählerumlauf benötigt wird, kann auch der fehlerhafte Wiederzusammenbau der Fragmente vermieden werden. Um dies zu erreichen, schreiben Sie den neuen Zeitüberschreitungswert (in Sekunden) in die Datei /proc/sys/net/ipv4/ipfrag_time.

Ein Wert von 2 Sekunden reduziert die Wahrscheinlichkeit von IP-Kennungszusammenstößen auf einer einzelnen Gigabit-Verbindung deutlich, erlaubt dabei aber auch noch eine vernünftige Zeitüberschreitung beim Empfang von fragmentiertem Verkehr von weit entfernten Teilnehmern.

»close-to-open«-Zwischenspeicherkohärenzsemantik

Typischerweise erfolgt das gemeinsame Benutzen von Dateien sequenziell. Zuerst öffnet Client A eine Datei, schreibt etwas hinein und schließt sie dann. Danach öffnet Client B die gleiche Datei und liest die Änderungen.

Wenn eine Anwendung eine auf einem NFS-3-Server gespeicherte Datei öffnet, überprüft der NFS-Client, ob die Datei noch auf dem Server existiert und dem Öffner erlaubt ist, indem er eine Anfrage GETATTR oder ACCESS sendet. Der NFS-Client sendet diese Anfragen unabhängig von der Frische der zwischengespeicherten Attribute der Datei.

Wenn die Anwendung die Datei schließt, schreibt der NFS-Client alle anhängenden Änderungen an der Datei zurück, so dass der nächste Öffner die Änderungen sehen kann. Dieses gibt dem NFS-Client eine Möglichkeit, alle Schreibfehler mittels des Rückgabewerts von close(2) mitzuteilen.

Das Verhalten der Prüfung zum Zeitpunkt des Öffnens und des Rückschreibens zum Zeitpunkt des Schließens wird als »close-to-open«-Zwischenspeicherkohärenzsemantik oder CTO bezeichnet. Sie kann für einen gesamten Einhängepunkt mit der Einhängeoption nocto deaktiviert werden.

Schwache Zwischenspeicherkohärenz

Es gibt immer noch Möglichkeiten für den Zwischenspeicher des Clients, abgelaufene Daten zu enthalten. Das NFS-Version-3-Protokoll führt die »schwache Zwischenspeicherkohärenz« ein (auch als WCC bekannt), die einen Weg beschreibt, mit der die Dateiattribute vor und nach einer Anfrage effizient überprüft werden können. Dies hilft einem Client, Änderungen, die durch andere Clients vorgenommen worden sein könnten, zu identifizieren.

Wenn ein Client viele parallele Aktionen einsetzt, die die gleiche Datei zur gleichen Zeit aktualisieren (beispielsweise während asynchronem verzögertem Schreiben), ist es immer noch schwierig, zu entscheiden, ob es diese Aktualisierungen des Clients oder Aktualisierungen auf einem anderen Client waren, die die Datei veränderten.

Attribut-Zwischenspeicherung

Verwenden Sie die Einhängeoption noac, um die Zwischenspeicherkohärenz für Attribute zwischen mehreren Clients zu erreichen. Fast jede Dateisystemaktion prüft Dateiattributinformationen. Die Clients halten diese Informationen für eine bestimmte Zeit im Zwischenspeicher, um Netz- und Server-Last zu reduzieren. Wenn noac aktiv ist, ist der Zwischenspeicher des Clients für Dateiattribute deaktiviert und daher muss jede Aktion, die die Dateiattribute prüft, zwingend zum Server gehen. Dies ermöglicht es einem Client, Änderungen sehr schnell zu erkennen, führt aber zu vielen zusätzlichen Netzaktionen.

Achtung: Verwechseln Sie die Option noac nicht mit »keine Daten-Zwischenspeicherung«. Die Einhängeoption noac hindert den Client daran, die Dateimetadaten zwischenzuspeichern, aber es gibt immer noch Ressourcenwettläufe, die zu Daten-Zwischenspeicher-Inkohärenzen zwischen Client und Server führen können.

Das NFS-Protokoll wurde nicht entwickelt, um echte Cluster-Dateisystem-Zwischenspeicherkohärenz zu unterstützen, ohne dass die Anwendungen eine Art von Serialisierung unterstützen. Falls zwischen den Clients eine absolute Zwischenspeicherkohärenz benötigt wird, sollten die Anwendungen das Sperren von Dateien einsetzen. Alternativ können Anwendungen ihre Dateien auch mit dem Schalter O_DIRECT öffnen, um das Zwischenspeichern der Daten komplett zu deaktivieren.

Dateizeitstempelverwaltung

NFS-Server sind dafür verantwortlich, die Datei- und Verzeichniszeitstempel (atime, ctime und mtime) zu verwalten. Wenn auf eine Datei zugegriffen oder diese auf dem NFS-Server aktualisiert wird, werden die Zeitstempel der Datei so aktualisiert, als ob sie relativ zu der Anwendung auf einem lokalen Dateisystem wären.

NFS-Clients speichern Dateiattribute, auch Zeitstempel, zwischen. Die Zeitstempel einer Datei werden auf den NFS-Clients aktualisiert, wenn seine Attribute von dem NFS-Server abgefragt werden. Daher kann es zu Verzögerungen kommen, bevor eine Zeitstempelaktualisierung auf dem NFS-Server für Anwendungen auf NFS-Clients sichtbar wird.

Um den POSIX-Dateisystemstandard zu erfüllen, verlässt sich der Linux-NFS-Client auf die NFS-Server, die Zeitstempel mtime und ctime der Datei korrekt aktuell zu halten. Um dies zu erreichen, schiebt er lokale Datenänderungen an den Server, bevor er mtime mittels Systemaufrufen wie stat(2) an Anwendungen meldet.

Der Linux-Client handhabt allerdings Aktualisierungen der atime lockerer. NFS-Clients halten eine gute Leistung, indem sie Daten zwischenspeichern, aber das bedeutet, dass Lesezugriffe von Anwendungen, die normalerweise die atime aktualisierten, nicht auf dem Server gespiegelt werden, wo die atime der Datei tatsächlich verwaltet wird.

Aufgrund dieses Zwischenspeicherverhaltens unterstützt der Linux-NFS-Client nicht die generischen Atime-bezogenen Einhängeoptionen. Siehe mount(8) für Details über diese Optionen.

Insbesondere haben die Einhängeoptionen atime/noatime, diratime/nodiratime, relatime/norelatime und strictatime/nostrictatime auf NFS-Einhängungen keinen Effekt.

/proc/mounts könnte berichten, dass die Einhängeoption relatime auf NFS-Einhängungen gesetzt ist, aber tatsächlich sind die atime-Semantiken immer wie hier beschrieben und nicht wie die relatime-Semantik.

Zwischenspeicherung von Verzeichniseinträgen

Der Linux-NFS-Client-Zwischenspeicher ist das Ergebnis aller »NFS LOOKUP«-Anfragen. Falls die angefragten Verzeichniseinträge auf dem Server existieren, wird das Ergebnis als positives Abfrageergebnis bezeichnet. Falls der angefragte Verzeichniseintrag nicht auf dem Server existiert (d.h. der Server ENOENT zurücklieferte), wird das Ergebnis als negatives Abfrageergebnis bezeichnet.

Um zu erkennen, wann Verzeichniseinträge auf dem Server hinzugefügt oder dort entfernt wurden, überwacht der Linux-NFS-Client die Mtime eines Verzeichnisses. Falls der Client eine Änderung in der Mtime des Verzeichnisses erkennt, beseitigt der Client alle zwischengespeicherten LOOKUP-Ergebnisse für dieses Verzeichnis. Da die Mtime des Verzeichnisses ein zwischengespeichertes Attribut ist, kann es einige Zeit dauern, bis der Client eine Änderung bemerkt. Siehe die Beschreibung der Einhängeoptionen acdirmin, acdirmax und noac für weitere Informationen darüber, wie lange die Mtime eines Verzeichnisses zwischengespeichert wird.

Das Zwischenspeichern von Verzeichniseinträgen verbessert die Leistung von Anwendungen, die Dateien nicht mit Anwendungen auf anderen Clients gemeinsam nutzen. Die Verwendung von zwischengespeicherten Informationen über Verzeichnisse kann allerdings Anwendungen durcheinanderbringen, die parallel auf mehreren Clients laufen und die die Erstellung und Entfernung von Dateien schnell erkennen müssen. Die Einhängeoption lookupcache erlaubt teilweise das Einstellen des Verhaltens der Verzeichniseintragszwischenspeicherung.

Vor Kernelveröffentlichung 2.6.28 verfolgte der Linux-NFS-Client nur positive Abfrageergebnisse. Dies ermöglichte Anwendungen, neue Verzeichniseinträge, die von anderen Clients erstellt wurden, schnell zu erkennen, und dabei immer noch einige der Leistungsvorteile des Zwischenspeichers zu genießen. Falls eine Anwendung von dem vorherigen Abfrageverhalten des Linux-NFS-Clients abhängt, können Sie lookupcache=positive verwenden.

Falls der Client seinen Zwischenspeicher ignoriert und jede Anwendungsnachschlageanfrage beim Server überprüft, kann der Client sofort erkennen, wenn ein neuer Verzeichniseintrag durch einen anderen Client entweder erstellt oder entfernt wurde. Sie können dieses Verhalten mittels lookupcache=none festlegen. Die zusätzlichen NFS-Anfragen, die benötigt werden, falls der Client Verzeichniseinträge nicht zwischenspeichert, kann eine Leistungseinbuße zur Folge haben. Deaktivieren des Zwischenspeicherns der Nachfragen sollte zu einer geringeren Leistungseinbuße führen als die Verwendung von noac und hat keinen Effekt darauf, wie der NFS-Client die Attribute von Dateien zwischenspeichert.

Die Einhängeoption »sync«

Der NFS-Client behandelt die Einhängeoption sync anders als einige andere Dateisysteme (lesen Sie mount(8) für eine Beschreibung der generischen Einhängeoptionen sync und async). Falls weder sync noch async angegeben ist (oder falls die Option async angegeben wurde) verzögert der NFS-Client das Versenden von Schreibanforderungen von Anwendungen an den Server, bis eines der folgenden Ereignisse auftritt:

Speicherdruck erzwingt die Zurückgewinnung von Systemspeicherressourcen.

Eine Anwendung schiebt explizit die Dateidaten mit sync(2), msync(2) oder fsync(3) raus.

Eine Anwendung schließt eine Datei mit close(2).

Die Datei wird mittels fcntl(2) gesperrt/entsperrt.

Mit anderen Worten, unter normalen Bedingungen können von einer Anwendung geschriebene Daten nicht sofort auf dem Server, der die Datei beherbergt, auftauchen.

Falls die Option sync am Einhängepunkt angegeben wurde, werden bei jedem Systemaufruf, der Daten in Dateien unter diesem Einhängepunkt schreibt, diese erst auf den Server geschrieben, bevor der Systemaufruf die Steuerung an den Benutzerraum zurückgibt. Damit wird größere Datenzwischenspeicherkohärenz unter den Clients erreicht, allerdings unter signifikanten Leitungseinbußen.

Anwendungen können den Schalter »O_SYNC« von open verwenden, um zu erzwingen, dass Schreibanforderungen von Anwendungen für bestimmte Dateien sofort an den Server gesandt werden, ohne die Einhängeoption sync zu verwenden.

Verwendung von Dateisperren mit NFS

Das Protokoll »Network Lock Manager« ist ein separates Seitenbandprotokoll, das zur Verwaltung von Dateisperren in NFS-Version 3 verwandt wird. Um das Wiederherstellen von Sperren nach einem Systemneustart eines Clients oder Servers zu unterstützen, ist ein zweites Seitenbandprotokoll – bekannt als »Network Status Manager«-Protokoll – notwendig. In NFS Version 4 wird das Sperren direkt im Haupt-NFS-Protokoll unterstützt und die NLM- und NSM-Seitenbandprotokolle werden nicht verwandt.

Meistens werden die Dienste NLM und NSM automatisch gestartet und es wird keine spezielle Konfiguration benötigt. Konfigurieren Sie alle NFS-Clients mit den vollqualifizierten Rechnernamen, um sicherzustellen, dass NFS-Server die Clients finden und sie über Server-Neustarts informieren können.

NLM unterstützt nur empfohlene Sperren. Um NFS-Dateien zu sperren, verwenden Sie fcntl(2) mit den Befehlen F_GETLK und F_SETLK. Der NFS-Client wandelt via flock(2) erworbene Dateisperren in empfohlene Sperren um.

Wenn von Servern, die nicht das NLM-Protokoll unterstützen, oder wenn von einem NFS-Server durch eine Firewall, die den NLM-Dienste-Port blockiert, eingehängt wird, dann verwenden Sie die Einhängeoption nolock. NLM-Sperren müssen mit der Option nolock ausgeschaltet werden, wenn /var mit NFS verwandt wird, da /var Dateien enthält, die von der NLM-Implementierung unter Linux verwandt werden.

Es wird auch empfohlen, die Option nolock zu verwenden, um die Leistung von proprietären Anwendungen, die auf einem einzelnen Client laufen und extensiv Dateisperren verwenden, zu verbessern.

Zwischenspeicherfunktionalitäten in NFS Version 4

Das Zwischenspeicherverhalten für Daten und Metadaten bei Clients der NFS-Version 4 ist ähnlich zu dem von älteren Versionen. Allerdings fügt NFS Version 4 zwei Funktionalitäten hinzu, die das Zwischenspeicherverhalten verbessern: Attributänderung und Datei-Delegation.

Die Attributänderung ist ein neuer Teil der NFS-Datei- und -Verzeichnis-Metadaten, die Änderungen nachverfolgt. Sie ersetzt die Verwendung von Zeitstempeln der Dateiänderung, um Clients zu ermöglichen, die Gültigkeit der Inhalte ihrer Zwischenspeicher zu überprüfen. Attributänderungen sind allerdings unabhängig von der Zeitstempelauflösung sowohl auf dem Server als auch auf dem Client.

Eine Datei-Delegation ist ein Vertrag zwischen einem NFS-Version-4-Client und einem Server, der es dem Client erlaubt, eine Datei temporär so zu behandeln, als ob kein anderer Client darauf zugreifen würde. Der Server verspricht dem Client, ihn zu benachrichtigen (mittels einer Rückrufanfrage), falls ein anderer Client versucht, auf die Datei zuzugreifen. Sobald eine Datei dem Client delegiert wurde, kann der Client aggressiv die Daten und Metadaten der Datei zwischenspeichern, ohne den Server zu benachrichtigen.

Datei-Delegationen gibt es in zwei Varianten: read und write. Eine read-Delegation bedeutet, dass der Server den Client über jeden anderen Client informiert, der in die Datei schreiben möchte. Eine write-Delegation bedeutet, dass der Client sowohl über Lese- als auch Schreibzugreifende informiert wird.

Server gewähren Datei-Delegationen, wenn eine Datei geöffnet wird und können diese jederzeit zurückfordern, wenn ein anderer Client auf die Datei zugreifen möchte und dies im Widerspruch zu bereits gewährten Delegationen steht. Delegationen von Verzeichnissen werden nicht unterstützt.

Um Delegations-Rückrufe zu unterstützen, prüft der Server während des ursprünglichen Kontakts des Clients mit dem Server den Rückkehrpfad zum Client. Falls der Kontakt mit dem Client nicht aufgebaut werden kann, gewährt der Server einfach diesem Client keine Delegationen.

Dateisystemwechsel in NFS Version 4

Das NFS-Version-4-Protokoll erlaubt es einem Client, die Sicherheitsvariante neu auszuhandeln, wenn der Client in ein neues Dateisystem auf dem Server wechselt. Die neu ausgehandelte Variante betrifft nur Zugriffe auf dem neuen Dateisystem.

Solche Aushandlungen treten typischerweise auf, wenn ein Client von einem Pseudodateisystem des Servers in eines der vom Server exportierten physischen Dateisysteme wechselt. Diese haben oft restriktivere Sicherheitseinstellungen als das Pseudodateisystem.

NFS-Version-4-Ausleihe

In NFS Version 4 ist eine Ausleihe (»lease«) eine Periode, in der der Server einem Client unumkehrbar Dateisperren gewährt. Sobald die Ausleihe abläuft, darf der Server diese Sperren zurückziehen. Clients erneuern ihre Ausleihe periodisch, um die Zurückziehung von Sperren zu vermeiden.

Nachdem ein NFS-Version-4-Server neustartet, teilt jeder Client dem Server mit, welche Dateien offen sind und welchen Sperrzustand unter seiner Ausleihe vorliegt, bevor die Arbeit fortgefahren werden kann. Falls ein Client neu startet, löst der Server alle offenen und Sperrzustände, die mit der Ausleihe des Clients verbunden sind.

Wenn eine Ausleihe etabliert wird, muss der Client sich daher beim Server identifizieren. Jeder Client zeigt eine beliebige Zeichenkette vor, um sich von anderen Clients zu unterscheiden. Der Client-Administrator kann die Vorgabe-Identitätszeichenkette mit dem Modulparameter nfs4.nfs4_unique_id ergänzen, um Kollisionen mit den Identifikationszeichenketten anderer Clients zu vermeiden.

Ein Client verwendet auch eine eindeutige Sicherheitsvariante und -Principal, wenn es eine Ausleihe etabliert. Falls zwei Clients die gleiche Identitätszeichenkette vorweisen, kann ein Server die Client-Principals verwenden, um zwischen beiden zu unterscheiden, und damit auf sichere Weise verhindern, dass Clients sich gegenseitig mit ihren Ausleihen in die Quere kommen.

Der Linux-NFS-Client etabliert eine Ausleihe auf jeden NFS-Version-4-Server. Ausleih-Verwaltungsaktionen, wie Ausleih-Erneuerung, werden nicht im Auftrag einer bestimmten Datei, Sperre, eines bestimmten Benutzers oder Einhängepunkts durchgeführt, sondern für den Client, dem die Ausleihe gehört. Ein Client verwendet eine konsistente Identitätszeichenkette, Sicherheitsvariante und Principal auch über Systemneustarte hinweg, um sicherzustellen, dass der Server schnell ausgelaufene Ausleihstati wiedererlangt.

Wenn auf einem Linux-NFS-Client Kerberos konfiguriert ist (d.h. es eine /etc/krb5.keytab auf diesem Client gibt), versucht der Client, eine Kerberos-Sicherheitsvariante für seine Ausleih-Verwaltungsaktionen zu verwenden. Kerberos bietet sichere Authentifizierung jedes Clients an. Standardmäßig verwendet der Client für diesen Zweck die Dienst-Principials host/ oder nfs/ in seiner /etc/krb5.keytab, wie dies in rpc.gssd(8) dargestellt ist.

Falls der Client aber nicht der Server Kerberos konfiguriert hat oder falls der Client keine Schlüsseltabelle oder die benötigten Server-Principals hat, verwendet der Client AUTH_SYS und UID 0 für die Ausleih-Verwaltung.

Verwendung nichtprivilegierter Quell-Ports

NFS-Clients kommunizieren normalerweise über Netz-Sockets mit dem Server. Jedes Ende eines Sockets wird ein Port-Wert zugeordnet. Dieser ist einfach eine Nummer zwischen 1 und 65535, der die Socket-Endpunkte auf der gleichen IP-Adresse unterscheidet. Ein Socket ist eindeutig durch das Tupel Transportprotokoll (TCP oder UDP), dem Port-Wert und der IP-Adresse beider Endpunkte definiert.

Der NFS-Client kann jeden Quell-Port-Wert für seine Sockets auswählen, nimmt aber gewöhnlich einen privilegierten Port. Ein privilegierter Port-Wert ist kleiner als 1024. Nur ein Prozess mit Root-Rechten kann einen Socket mit einem privilegierten Quell-Port erstellen.

Der genaue Bereich der auswählbaren privilegierten Quell-Ports wird durch ein Sysctl-Paar ausgewählt, um gut bekannte Ports zu vermeiden, wie den von SSH verwandten Port. Das bedeutet, dass die Anzahl der für den NFS-Client verfügbaren Quell-Ports und damit die Anzahl der Socket-Verbindungen, die gleichzeitig verwandt werden können, praktisch auf nur einige Hundert begrenzt ist.

Wie oben beschrieben, verlässt sich das traditionelle Standard-NFS-Authentifizierungsschema, bekannt als AUTH_SYS, auf das Senden der lokalen UID und GID-Nummern, um Benutzer, die NFS-Anfragen stellen, zu identifizieren. Ein NFS-Server nimmt an, dass die UID und GID-Nummer in den NFS-Anfragen auf dieser Verbindung vom Client-Kernel oder einer anderen lokalen Autorität überprüft wurde, falls die Verbindung von einem privilegierten Port kommt. Dieses System ist leicht zu täuschen, aber in vertrauenswürdigen physischen Netzen zwischen vertrauenswürdigen Rechnern ist es vollkommen angemessen.

Grob gesprochen wird ein Socket für jeden NFS-Einhängepunkt verwandt. Falls ein Client auch nichtprivilegierte Quell-Ports verwenden könnte, wäre die Anzahl der erlaubten Sockets und damit die maximale Anzahl an gleichzeitigen Einhängepunkten viel größer.

Die Verwendung nichtprivilegierter Quell-Ports könnte die Server-Sicherheit etwas beeinträchtigen, da jeder Benutzer auf AUTH_SYS-Einhängepunkten bei NFS-Anfragen jetzt vorgeben kann, ein beliebiger anderer zu sein. Daher unterstützen NFS-Server dies standardmäßig nicht. Normalerweise erlauben sie dies über eine explizite Export-Option.

Um gute Sicherheit zu wahren und gleichzeitig so viele Einhängepunkte wie möglich zu erlauben, ist es am besten, nichtprivilegierte Ports nur zu erlauben, falls der Server und der Client beide eine starke Authentifizierung wie Kerberos verlangen.

Einhängen durch eine Firewall

Eine Firewall könnte zwischen einem NFS-Client und -Server liegen, oder der Client oder der Server könnte einige seiner eigenen Ports über IP-Filterregeln blockieren. Es ist weiterhin möglich, einen NFS-Server durch eine Firewall einzuhängen, allerdings könnten einige der automatischen Serverendpunktentdeckungsmechanismen des Befehls mount(8) nicht funktionieren. Daher müssen Sie dann spezifische Endpunktdetails über NFS-Einhängeoptionen bereitstellen.

NFS-Server betreiben normalerweise einen Portmapper oder einen Rpcbind-Daemon, um ihre Diensteendpunkte den Clients bekanntzugeben. Clients verwenden den Rpcbind-Daemon, um zu ermitteln:

Welchen Netzwerk-Port jeder RPC-basierte Dienst verwendet

Welches Transportprotokoll jeder RPC-basierte Dienst unterstützt

Der Rpcbind-Daemon verwendet eine gut bekannte Port-Nummer (111), damit Clients einen Diensteendpunkt finden. Obwohl NFS oft eine Standard-Port-Nummer (2049) verwendet, können Hilfsdienste wie der NLM-Dienst jede unbenutzte Port-Nummer zufällig auswählen.

Typische Firewall-Konfigurationen blockieren den gut bekannten Rpcbind-Port. Ohne den Rpcbind-Dienst kann der Administrator die Port-Nummer von Diensten mit Bezug zu NFS festlegen, so dass die Firewall Zugriff auf bestimmte NFS-Dienste-Ports erlauben kann. Client-Administratoren legen dann die Port-Nummer für den Mountd-Dienst mittels der Option mountport des Befehls mount(8) fest. Es kann auch notwendig sein, die Verwendung von TCP oder UDP zu erzwingen, falls die Firewall einen dieser Transporte blockiert.

NFS-Zugriffssteuerlisten

Solaris erlaubt NFS-Version-3-Clients direkten Zugriff auf die auf seinen lokalen Dateisystemen gespeicherten POSIX-Zugriffsteuerlisten. Dieses proprietäre Seitenbandprotokoll namens NFSACL stellt eine umfassendere Zugriffssteuerung als die Modusbits bereit. Linux implementiert dieses Protokoll zur Kompatibilität mit der Solaris-NFS-Implementierung. Das NFSACL-Protokoll wurde allerdings niemals ein Standardteil der NFS-Version-3-Spezifikation.

Die NFS-Version-4-Spezifikation verlangt eine neue Version der Zugriffssteuerlisten, die semantisch reicher als POSIX ACLs ist. NFS-Version-4-ACLs sind mit den POSIX ACLs nicht voll kompatibel, daher ist eine Übersetzung zwischen den beiden in Umgebungen, die POSIX ACLs und NFS Version 4 vermischen, notwendig.

Aushängen nach einem erneuten Einhängen

Für Einhängepunkte, die NFS Version 2 oder 3 verwenden, hängt der NFS-Unterbefehl umount davon ab, die ursprüngliche Menge der Einhängeoptionen zu kennen, die zur Ausführung der MNT-Aktion verwandt wurden. Diese Optionen werden durch den NFS-Unterbefehl mount auf Platte gespeichert und können durch erneutes Einhängen gelöscht werden.

Um sicherzustellen, dass die gespeicherten Einhängeoptionen während eines erneuten Einhängens nicht gelöscht werden, geben Sie während eines erneuten Einhängens entweder das lokale Einhängeverzeichnis oder den Rechnernamen und den Exportpfadnamen, aber nicht beide, an. Beispielsweise fügt

	mount -o remount,ro /mnt

die Einhängeoption ro mit den bereits auf Platte gespeicherten, für den unter /mnt eingehängten NFS-Server zusammen.