Freigeben über


Opportunistische Sperrbeispiele

Die folgenden Beispiele zeigen Daten- und SMB-Nachrichtenbewegungen, da opportunistische Sperren vorgenommen und unterbrochen werden. Beachten Sie, dass Clients Datei-Attributdaten sowie Dateidaten zwischenspeichern können.

Beachten Sie außerdem, dass diese Beispiele auf Situationen basieren, in denen Clientanwendungen opportunistische Sperren von Remoteservern anfordern. Diese Prozesse werden automatisch vom Netzwerkumleitungs- und Remoteserver initiiert – es gibt keine direkte Beteiligung der Clientanwendung oder -anwendungen. Die in diesen Beispielen beschriebenen Prozesse können in Situationen generalisiert werden, in denen lokale Clientanwendungen direkt opportunistische Sperren aus dem lokalen Dateisystem anfordern, mit der Ausnahme, dass kein Datenaustausch über das Netzwerk beteiligt ist.

Opportunistische Sperre der Ebene 1

Das folgende Diagramm zeigt eine Ansicht des Netzwerkdatenverkehrs einer opportunistischen Sperre der Ebene 1 für eine Datei. Die Pfeile geben ggf. die Richtung der Datenbewegung an.

Ereignis Client X Server Client Y
1 Öffnet Datei, Anforderungen Ebene 1 Sperr ==>
2 <== Grant Level 1 opportunistische Sperre
3 Führt Lese-, Schreib- und andere Vorgänge aus ==>
4 <== Anforderungen zum Öffnen der Datei
5 <== Bricht opportunistische Sperre
6 Verwirft Lese-/Vorlesedaten
7 Schreibt Daten ==>
8 Sendet die Nachricht "close" oder "done" ==>
9 Oks Open Operation ==>
10 Führt Lese-, Schreib- und andere Vorgänge aus ==> <== Führt Lese-, Schreib- und andere Vorgänge aus.

 

In Ereignis 1 öffnet Client X eine Datei und fordert als Teil des geöffneten Vorgangs eine opportunistische Sperre der Ebene 1 für die Datei an. In Ereignis 2 gewährt der Server die Sperre der Ebene 1, da kein anderer Client die Datei geöffnet hat. Der Client fährt fort, auf die Datei in der üblichen Weise in Ereignis 3 zuzugreifen.

In Ereignis 4 versucht client Y, die Datei zu öffnen und fordert eine opportunistische Sperre an. Der Server sieht, dass client X die Datei geöffnet hat. Der Server ignoriert die Anforderung von Y, während Client X alle Schreibdaten löscht und den Lesecache für die Datei aufgibt.

Der Server zwingt X, X zu bereinigen, indem eine SMB-Nachricht gesendet wird, die die opportunistische Sperre unterbricht, Ereignis 5. Client X "im Hintergrund" verwirft alle Lese-Ahead-Daten; Mit anderen Worten, dieser Prozess generiert keinen Netzwerkdatenverkehr. In Ereignis 7 schreibt Client X alle zwischengespeicherten Schreibdaten auf den Server. Wenn client X mit dem Schreiben zwischengespeicherter Daten auf dem Server fertig ist, sendet Client X entweder eine "Schließen"- oder eine "Fertig"-Nachricht an den Server, Ereignis 8.

Nachdem der Server benachrichtigt wurde, dass client X den Schreibcache auf den Server leeren oder die Datei geschlossen hat, kann der Server die Datei für Client Y öffnen, in Ereignis 9. Da der Server jetzt zwei Clients mit der gleichen Datei geöffnet hat, gewährt er keine opportunistische Sperre. Beide Clients fahren mit dem Lesen aus der Datei fort, und eine oder keine Schreibvorgänge in die Datei.

Opportunistische Batchsperre

Das folgende Diagramm zeigt eine Ansicht des Netzwerkdatenverkehrs einer opportunistischen Batchsperre. Die Pfeile geben ggf. die Richtung der Datenbewegung an.

Ereignis Client X Server Client Y
1 Öffnet Datei, Fordert Batchsperre ==>
2 <== Grant Batch opportunistische Sperre
3 Lesedatei ==>
4 <== Sendet Daten
5 Schließt die Datei
6 Öffnet die Datei.
7 Sucht nach Daten
8 Liest Daten ==>
9 <== Sendet Daten
10 Schließt die Datei
11 <== Öffnet die Datei
12 <== Bricht opportunistische Sperre
13 Schließt die Datei ==>
14 Oks Open Operation ==>
15 <== Führt Lese-, Schreib- und andere Vorgänge aus.

 

In der opportunistischen Batchsperre öffnet Client X eine Datei, ein Ereignis 1, und der Server gewährt Client X eine Batchsperre in Ereignis 2. Client X versucht, Daten zu lesen, Ereignis 3, auf die der Server mit Daten reagiert, Ereignis 4.

Ereignis 5 zeigt die opportunistische Batchsperre bei der Arbeit an. Die Anwendung auf Client X schließt die Datei. Der Netzwerkumleitung filtert jedoch den Schließen-Vorgang aus und überträgt keine Close-Nachricht, wodurch eine "stille" Schließung ausgeführt wird. Der Netzwerkumleitungsmodul kann dies tun, da Client X den alleinigen Besitz der Datei besitzt. Später öffnet die Anwendung in Ereignis 6 die Datei erneut. Auch hier fließen keine Daten über das Netzwerk hinweg. Was den Server betrifft, hat dieser Client die Datei seit Ereignis 2 geöffnet.

Die Ereignisse 7, 8 und 9 zeigen den üblichen Verlauf des Netzwerkdatenverkehrs. In Ereignis 10 tritt eine weitere automatische Schließung auf.

In Ereignis 11 versucht client Y, die Datei zu öffnen. Die Serveransicht der Datei besteht darin, dass client X sie geöffnet hat, obwohl die Anwendung auf Client X sie geschlossen hat. Daher sendet der Server eine Nachricht, die die opportunistische Sperre an Client X unterbricht. Client X sendet jetzt die schließende Nachricht über das Netzwerk, Ereignis 13. Ereignis 14 folgt, wenn der Server die Datei für Client Y öffnet. Die Anwendung auf Client X hat die Datei geschlossen, sodass die Datei nicht mehr an den Server für diese Datei übertragen oder vom Server übertragen wird. Client Y beginnt die Datenübertragung wie üblich bei Ereignis 15.

Zwischen dem Zeitpunkt, zu dem Client X die Sperre für die Datei in Ereignis 2 und dem endgültigen Schließen bei Ereignis 13 gewährt wird, sind alle Dateidaten, die der Client zwischengespeichert hat, gültig, obwohl die dazwischen liegende Anwendung geöffnet und geschlossen wird. Nachdem die opportunistische Sperre unterbrochen wurde, können zwischengespeicherte Daten jedoch nicht als gültig betrachtet werden.

Opportunistische Sperre filtern

Das folgende Diagramm zeigt eine Netzwerkdatenverkehr-Ansicht einer opportunistischen Filtersperre. Die Pfeile geben ggf. die Richtung der Datenbewegung an.

Ereignis Client X Server Client Y
1 Öffnet die Datei ohne Zugriffsrechte ==>
2 <== Öffnet die Datei.
3 Filtersperre für Anforderungen==>
4 <== Grant Lock
5 Öffnet die Datei zum Lesen ==>
6 <== Öffnet die Datei erneut.
7 Liest Daten mithilfe des Lesekästchens ==>
8 <== Sendet Daten
9 <== Sendet Daten
10 <== Sendet Daten
11 <== Öffnet die Datei.
12 Öffnet die Datei ==>
13 <== Filtersperre für Anforderungen
14 Filtersperre verweigert==>
15 <== Liest Daten
16 Sendet Daten ==>
17 Liest (zwischengespeicherte) Daten
18 Schließt die Datei ==>
19 <== Datei schließt

 

In der opportunistischen Filtersperre öffnet Client X eine Datei, ein Ereignis 1, und der Server antwortet in Ereignis 2. Der Client fordert dann eine opportunistische Filtersperre in Ereignis 3 an, gefolgt von dem Server, der die opportunistische Sperre in Ereignis 4 gewährt. Client X öffnet dann die Datei erneut zum Lesen in Ereignis 5, auf die der Server in Ereignis 6 antwortet. Der Client versucht dann, Daten zu lesen, auf die der Server mit Daten antwortet, Ereignis 8.

Ereignis 9 zeigt die opportunistische Filtersperre bei der Arbeit an. Der Server liest den Client vor und sendet die Daten über das Netzwerk, obwohl der Client sie nicht angefordert hat. Der Client speichert die Daten zwischen. In Ereignis 10 erwartet der Server auch eine zukünftige Anforderung für Daten und sendet einen anderen Teil der Datei für den Client zwischenzuspeichern.

In Ereignis 11 und 12 öffnet ein anderer Client, Y, die Datei. Client Y fordert auch eine opportunistische Filtersperre an. In Ereignis 14 verweigert der Server sie. In Ereignis 15 fordert client Y Daten an, die der Server in Ereignis 16 sendet. Keiner davon wirkt sich auf Client X aus. Jederzeit kann ein anderer Client diese Datei für den Lesezugriff öffnen. Kein anderer Client wirkt sich auf die Filtersperre von Client X aus.

Ereignis 17 zeigt Client X-Lesedaten an. Da der Server die Daten jedoch bereits gesendet hat und der Client sie zwischengespeichert hat, überschreitet kein Datenverkehr das Netzwerk.

In diesem Beispiel versucht Client X niemals, alle Daten in der Datei zu lesen, sodass der von den Ereignissen 9 und 10 angegebene Lesevorgang "verschwendet" ist; d. h., die Daten werden niemals tatsächlich verwendet. Dies ist ein akzeptabler Verlust, da die Anwendung durch den Lesevorgang beschleunigt wurde.

In Ereignis 18 schließt Client X die Datei. Der Netzwerkumleitungsmodul des Clients gibt die zwischengespeicherten Daten auf. Der Server schließt die Datei.