[Kapitel 5] 5.5 Locks und Oplocks

5.5 Locks und Oplocks

Das Schreiben von Konkurrenten in eine einzelne Datei ist nicht wünschenswert in irgendeinem Betriebssystem. Um dies zu verhindern, verwenden die meisten Betriebssysteme locks, damit garantiert ist, dass nur ein Prozess während der Zeit in eine Datei schreiben kann. Betriebssysteme blockieren üblicherweise die gesamten Dateien, obwohl die neueren erlauben, eine Reihenfolge von Bytes in einer Datei zu blockieren. Wenn ein anderer Prozess versucht, in eine Datei zu schreiben (oder in einen Abschnitt einer Datei), die bereits blockiert ist, bekommt er einen Fehler vom Betriebssystem und wird warten, bis der Lock freigegeben ist.

Samba unterstützt die Standard DOS- und NT Dateisystem- (deny-mode) Blockieranfragen, welche nur einem Prozess erlauben, in eine Datei als Ganze auf einem Server während einer gegebenen Zeit zu schreiben, sowie Byte-Range-Locking. Zusätzlich unterstützt Samba einen neuen Blockier-Mechanismus, in der Windows NT-Welt kurz als opportunistic locking - oplock bekannt.

5.5.1 Opportunistic Locking

Opportunistic Locking erlaubt einem Client, den Sambaserver zu benachrichtigen, dass nicht er allein der ausschließliche Schreiber in eine Datei ist, aber auch seine Veränderungen in diese Datei auf seiner eigenen Maschine (und nicht auf dem Sambaserver) speichert, um den Dateizugriff für diesen Client zu beschleunigen. Wenn Samba weiß, dass eine Datei von einem Client "passend gesperrt" wurde, markiert es seine Version als Besitzer eines Opportunistic Lock und wartet auf den Client, um die Arbeit an der Datei zu vollenden, an deren Punkt es erwartet, dass der Client die letzten Änderungen für die Synchronisation zurück zum Sambaserver schickt.

Wenn ein zweiter Client Zugriff auf diese Datei verlangt, bevor der erste Client die Arbeit mit ihr beendet hat, kann Samba dem ersten Client eine oplock break-Anfrage senden. Das sagt dem Client, er solle das Caching seiner Änderungen stoppen und den aktuellen Stand der Datei dem Server retournieren, sodass der unterbrechende Client sie benützen kann, wie er es für richtig hält. Ein Opportunistic Lock ist kein Ersatz für einen Standard Deny-Mode-Lock. Es ist nicht bespiellos für den unterbrechenden Prozess, einen Oplock Break bewilligt zu bekommen, nur um zu entdecken, dass der Originalprozess ebenfalls einen Deny-Mode-Lock auf einer Datei besitzt. Figur 5.8 illustriert diesen Opportunistic-Locking-Prozess.

Figur 5.8: Opportunistic locking

Was Locks betrifft, empfehlen wir dringend den Gebrauch der von Samba gebotenen Voreinstellungen: Standard DOS/Windows Deny-Mode-Locks für Kompatibilität und Oplocks für die zusätzliche Leistung, die lokales Caching erlaubt. Wenn dein Betriebssystem den Vorteil von Oplocks wahrnehmen kann, sollte es wichtige Leistungs-Verbesserungen zur Verfügung stellen. Außer wenn du einen besonderen Grund zum Ändern irgendwelcher dieser Optionen hast, ist es das Beste, sie so zu lassen wie sie sind.

5.5.2 Unix und Locking

Windows-Systeme arbeiten gut zusammen, damit sie einander nicht die Veränderungen überschreiben. Aber wenn auf eine auf einem Samba-System gespeicherte Datei von einem Unix-Prozess zugegriffen wird, wird dieser Prozess nichts über Windows-Oplocks wissen und könnte leicht rücksichtslos über einen Lock hinweggehen. Einige Unix-Systeme wurden erweitert, damit sie die von Samba versorgten Windows-Oplocks verstehen. Momentan existiert die Unterstützung nur in SGI Irix 6.5.2f und später; Linux und FreeBSD sollten bald folgen.

Wenn du ein System hast, das mit Oplocks umgehen kann, trag kernel oplocks = yes in die Samba Konfigurationsdatei ein. Das sollte Konflikte zwischen Unix-Prozessen und Windows-Usern ausschalten.

Wenn dein System Kernel-Oplocks nicht unterstützt, könntest du mit zerstörten Daten enden, sobald jemand einen Unix-Prozess laufen hat, der eine Datei liest oder schreibt, auf die Windows-User auch zugreifen. Nun, Samba bietet einen primitiven Schutz-Mechanismus in der Abwesenheit von Kernel-Oplocks: die Option veto oplock files. Wenn du voraussehen kannst, welche Samba-Dateien von Windows- und Unix-Usern verwendet werden, so setz deren Namen in eine veto oplock files-Option. Das wird die Verwendung von Oplocks auf übereinstimmenden Dateinamen unterdrücken, was das Client-Caching unterdrückt, und lässt die Windows- und Unix-Programme System-Locking oder Update-Momente verwenden, um eine Konkurrenz um dieselbe Datei zu entdecken. Eine Musteroption ist:

veto oplock files = /*.dbm/

Diese Option erlaubt Unix-Prozessen und Windows-Usern, Dateien mit der Endung .dbm zu editieren. Beachte, dass die Syntax dieser Option dem Befehl veto files ähnelt.

Sambas Optionen für Locks und Oplocks werden in Tabelle 5.8 gezeigt.

Tabelle 5.8: Locks und Oplocks, Konfigurationsoptionen
Option	Parameter	Funktion	Vorgabe	Bereich
`share modes`	boolean	Wenn auf `yes` gesetzt, schaltet die Unterstützung für DOS-artige Ganzdatei-Locks ein.	`yes`	Share
`locking`	boolean	Wenn `yes`, schaltet Byte-Range-Locks ein.	`yes`	Share
`strict locking`	boolean	Wenn `yes`, sperrt den Zugriff zu einer ganzen Datei, wenn ein Byte-Range-Lock darin existiert.	`no`	Share
`oplocks`	boolean	Wenn `yes`, dreht das lokale Caching von Dateien auf dem Client für diese Share auf.	`yes`	Share
`kernel oplocks`	boolean	Wenn `yes`, bedeutet, dass der Kernel Oplocks unterstützt.	`yes`	Global
`fake oplocks`	boolean	Wenn `yes`, sagt dem Client, der Lock wurde erworben, aber er sperrt ihn momentan nicht.	`no`	Share
`blocking locks`	boolean	Erlaubt dem Lock-Anforderer, auf den Lock zu warten, damit er bewilligt wird.	`yes`	Share
`veto oplock files`	string (Liste von Dateinamen)	Kein Oplock für die genannten Dateien.	None	Share
`lock directory`	string (Voller Pfadname)	Legt den Ort fest, wo verschiedene Sambadateien einschließlich Locks gespeichert werden.	Wie im Samba-Makefile festgelegt wurde	Global

5.5.2.1 share modes

Die einfachsten Locks, die auf Samba vorkommen, sind Deny-Mode-Locks, als share modes bekannt, welche von Programmen wie Texteditoren eingesetzt werden, um zufälliges Überschreiben von Dateien zu vermeiden. Zur Referenz werden die Deny-Mode-Locks in Tabelle 5.9 angeführt.

Tabelle 5.9: SMB Deny-Mode Locks
Lock	Beschreibung
`DENY_NONE`	Verbiete keine anderen Dateianfragen.
`DENY_ALL`	Sperre alle Anfragen zum Öffnen der momentanen Datei.
`DENY_READ`	Sperre Anfragen zum Öffnen der momentanen Datei zwecks Lesen.
`DENY_WRITE`	Sperre Anfragen zum Öffnen der momentanen Datei zwecks Schreiben.
`DENY_DOS`	Wenn zum Lesen geöffnet, können andere die Datei lesen aber nicht beschreiben. Wenn zum Schreiben geöffnet, können andere die Datei überhaupt nicht öffnen.
`DENY_FCB`	Veraltet.

Der Parameter share modes, welcher dem Gebrauch dieser Locks Geltung verschafft, ist in der Voreinstellung eingeschaltet. Um ihn auszuschalten, benütze folgenden Befehl:

[accounting]
	share modes = no

Wir empfehlen dringend, den voreingestellten Lock-Mechanismus nicht auszuschalten, außer du hast einen triftigen Grund für dein Vorgehen. Die meisten Windows- und DOS-Applikationen verlassen sich auf diese Lock-Mechanismen für korrektes Arbeiten und beklagen sich bitterlich, wenn diese Funktionalität entfernt wird.

5.5.2.2 locking

Die Option locking kann benützt werden, Samba mitzuteilen, serverseitige Byte-Range-Locks im Namen des Clients zu engagieren oder nicht. Samba führt Byte-Range-Locks auf Seiten des Servers mit normalen Unix Advisory(Beratenden)-Locks durch und wird andere sich richtig verhaltende Unix-Prozesse konsequent daran hindern, eine gesperrte Byte-Range zu überschreiben.

Diese Option kann in der Share wie folgt festgelegt werden:

[accounting]
	locking = yes

Wenn die Option locking auf yes gesetzt ist, wird der Anfragende aufgehalten, bis der Besitzer eines Lock-Typs ihn freigibt (oder abstürzt). Wenn nun die Option auf no gesetzt ist, werden keine Byte-Range-Locks für die Dateien genommen, obwohl Anfragen, Dateien zu sperren oder freizugeben, anscheinend gelingen. Die Voreinstellung dieser Option ist yes; du kannst jedoch diese Option ausschalten, wenn du ein read-only Medium hast.

5.5.2.3 strict locking

Diese Option prüft jeden Dateizugriff wegen eines Byte-Range-Locks, auf den in der Reihenfolge der Bytes zugegriffen wird. Das wird üblicherweise nicht gebraucht, wenn ein Client an der Stelle alle Lock-Mechanismen beibehält. Diese Option ist auf no voreingestellt; du kannst sie jedoch in der Share umändern wie folgt:

[accounting]
	strict locking = yes

Ist diese Option auf yes gesetzt, werden verpflichtende Locks auf jeder Datei mit Byte-Range-Locks durchgeführt.

5.5.2.4 blocking locks

Samba unterstützt auch blocking locks, eine kleinere Variante der Range-Locks. Wenn hier der Bereich der Bytes nicht verfügbar ist, bestimmt der Client eine Zeitspanne, die er bereit ist zu warten. Der Server cacht dann die Lock-Anfrage und schaut periodisch nach, ob die Datei zur Verfügung steht. Ist das der Fall, so benachrichtigt er den Client; wenn nun die Zeit abläuft, wird Samba dem Client sagen, dass die Anfage gescheitert ist. Diese Strategie schützt den Client vor dauerndem Wählen, um nachzuschauen, ob der Lock verfügbar ist.

Du kannst diese Option in der Share abschalten wie folgt:

[accounting]
	blocking locks = no

Sobald auf yes gesetzt, werden die Blocking Locks an der Datei durchgeführt. Wenn diese Option auf no gesetzt ist, verhält sich Samba so, als ob normale Lock-Mechanismen anstelle der Datei wären. Die Vorgabe ist yes.

5.5.2.5 oplocks

Diese Option ermöglicht oder sperrt die Unterstützung für Oplocks auf dem Client. Die Option ist in der Voreinstellung eingeschaltet. Du kannst sie aber mit dem folgenden Befehl ausschalten:

[data]
	oplocks = no

Wenn du in einer extrem instabilen Netzwerkumgebung bist oder viele Clients hast, die keinen Vorteil aus dem Opportunistic Locking ziehen, könnte es besser sein, dieses Samba-Feature abzuschalten. Oplocks sollten abgeschaltet werden, wenn du von Unix-Applikationen (wie vi) und SMB-Clients aus (außer du bist in der glücklichen Lage, ein Betriebssystem zu besitzen, das Kernel-Oplocks unterstützt, wie vorher besprochen) auf dieselben Dateien zugreifst.

5.5.2.6 fake oplocks

Bevor Opportunistic Locking auf Samba zur Verfügung stand, täuschten die Samba-Dämonen über die Option fake oplocks vor, Oplocks zu erlauben. Wenn diese Option eingeschaltet war, wurde allen Clients gesagt, dass die Datei für Opportunistic Locking verfügbar sei, und nie vor gleichzeitigem Zugriff gewarnt. Diese Option hat nun an Wert verloren, weil wirkliche Oplocks auf Samba zur Verfügung stehen.

5.5.2.7 kernel oplocks

Wenn eine Unix-Applikation getrennt von Samba ein Update einer Datei versucht, die Samba zu einem Windows-Client opgelockt hat, wird es wahrscheinlich gelingen (abhängig vom Betriebssystem), und Samba und der Client werden sich darüber nie im Klaren sein. Wenn nun das lokale Unix-System es unterstützt, kann Samba es vor Oplocked-Dateien warnen, die den Unix-Prozess aufschieben können, den Client via Samba benachrichtigen können, damit er seine Kopie zurückschreibt, und nur dann erlaubt, das Öffnen zu beenden. Das bedeutet im Wesentlichen, dass der Betriebssystem-Kernel auf dem Samba-System die Fähigkeit besitzt, Oplocks sowie Samba zu handhaben.

Du kannst dieses Verhalten mit der Option kernel oplocks einschalten, wie folgt:

[global]
	kernel oplocks = yes

Samba kann Kernel-Oplocks automatisch erkennen und sie benützen, wenn sie vorhanden sind. Zur Zeit der Arbeit an diesem Buch wird dieses Feature nur von SGI Irix 6.5.2f und später unterstützt. Nun, Linux- und FreeBSD-Unterstützung wird in naher Zukunft erwartet. Ein System ohne Kernel-Oplocks erlaubt dem Unix-Prozess, die Datei upzudaten, aber die Client-Programme werden die Änderung erst zu einem späteren Zeitpunkt bemerken, wenn überhaupt.

5.5.2.8 veto oplock files

Du kannst eine Liste von Dateinamen bereitstellen, denen mit der Option veto oplock files niemals Opportunistic Locks gewährt werden. Diese Option kann entweder global oder auf Basis einer Share bestimmt werden. Ein Beispiel:

veto oplock files = /*.bat/*.htm/

Der Wert dieser Option ist eine Reihe von Mustern. Jeder Muster-Eintrag muss mit einem Slash (/) beginnen, enden oder von einem anderen Muster getrennt werden, sogar wenn nur ein Muster angeführt ist. Sternchen können als eine Wildcard verwendet werden und für Null oder mehr Zeichen stehen. Fragezeichen können nur an Stelle von genau einem Zeichen verwendet werden.

Wir empfehlen, dass du die Oplocks auf allen Dateien sperrst, die von Unix upgedatet werden sollen oder zum gleichzeitigen Aufteilen unter einigen Prozessen gedacht sind.

5.5.2.9 lock directory

Diese Option (manchmal lock dir genannt) bestimmt den Ort eines Verzeichnisses, wo Samba SMB Deny-Mode-Lock-Dateien speichert. Samba speichert auch andere Dateien in diesem Verzeichnis, wie Browse-Listen und seine Shared-Memory-Datei. Wenn WINS in Verwendung ist, wird auch die WINS-Datenbank in dieses Verzeichnis geschrieben. Die Voreinstellung für diese Option ist im Samba-Makefile festgelegt; es ist typischerweise /usr/local/samba/var/locks. Du kannst diesen Ort umändern wie folgt:

[global]
	lock directory = /usr/local/samba/locks

Üblicherweise würdest du diese Option nicht ändern müssen, außer du willst die Lock-Dateien an eine mehr normierte Stelle wie /var/spool/locks befördern.


5.4 Name Mangling und Case		6. User, Security und Domains

Using Samba