Beispiele für opportunistische Sperre

Die folgenden Beispiele zeigen Daten- und SMB-Nachrichtenverschiebungen, wenn opportunistische Sperren vorgenommen und beschädigt werden. Beachten Sie, dass Clients Sowohl Dateiattributedaten als auch Dateidaten zwischenspeichern können.

Beachten Sie auch, dass diese Beispiele auf Situationen basieren, in denen Clientanwendungen opportunistische Sperren von Remoteservern anfordern. Diese Prozesse werden automatisch vom Netzwerkumleitungsor und dem Remoteserver initiiert. Die Clientanwendung oder -anwendungen sind nicht direkt beteiligt. Die in diesen Beispielen beschriebenen Prozesse können in Situationen generalisiert werden, in denen lokale Clientanwendungen direkt opportunistische Sperren vom lokalen Dateisystem anfordern, mit der Ausnahme, dass kein Datenaustausch über das Netzwerk erfolgt.

Stufe 1 Opportunistische Sperre

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 Datenverschiebung an.

Ereignis	Client X	Server	Client Y
1	Öffnet die Datei, fordert Sperre der Ebene 1 an .>
2		<== Gewährt Stufe 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 Read-Ahead-Daten.
7	Schreibt Daten .>
8	Sendet "Close"- oder "Done"-Nachricht ==>
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 im Rahmen 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 die Datei auf keinem anderen Client geöffnet ist. Der Client greift in Ereignis 3 wie gewohnt auf die Datei zu.

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

Der Server erzwingt, dass X sauber, indem eine SMB-Nachricht an X gesendet wird, die die opportunistische Sperre (Ereignis 5) durchbricht. Client X verwirft alle Read-Ahead-Daten "im Hintergrund". 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 von zwischengespeicherten Daten auf den Server fertig ist, sendet Client X entweder eine "Close"- oder "Done"-Nachricht an den Server( Ereignis 8).

Nachdem der Server benachrichtigt wurde, dass Client X seinen Schreibcache auf den Server geleert hat oder die Datei geschlossen hat, kann der Server die Datei für Client Y in Ereignis 9 öffnen. Da der Server jetzt über zwei Clients verfügt, für die dieselbe Datei geöffnet ist, gewährt er keinem eine opportunistische Sperre. Beide Clients lesen weiter aus der Datei, und einer oder keiner schreibt in die Datei.

Batch-opportunistische Sperre

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

Ereignis	Client X	Server	Client Y
1	Öffnet die Datei, fordert die Batchsperre an.>
2		<== Gewährt batch opportunistische Sperre
3	Liest die Datei ==>
4		<== Sendet Daten.
5	Schließt die Datei
6	Öffnet eine 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 datei ==>
14		Oks open operation ==>
15			<== Führt Lese-, Schreib- und andere Vorgänge aus.

 

In der batchoprtunistischen Sperre öffnet Client X eine Datei (Ereignis 1), und der Server gewährt Client X in Ereignis 2 eine Batchsperre. Client X versucht, Daten zu lesen, Ereignis 3, auf die der Server mit Daten antwortet, Ereignis 4.

Ereignis 5 zeigt die batchoprtunistische Sperre bei der Arbeit an. Die Anwendung auf Client X schließt die Datei. Der Netzwerkumleitungsor filtert jedoch den Close-Vorgang heraus und überträgt keine Close-Nachricht, sodass ein "silent"-Schließen ausgeführt wird. Der Netzwerkumleitung kann dies tun, da Client X den alleinigen Besitzer der Datei hat. Später, in Ereignis 6, öffnet die Anwendung die Datei erneut. Auch hier fließen keine Daten über das Netzwerk. 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 an. In Ereignis 10 tritt ein weiteres automatisches Schließen auf.

In Ereignis 11 versucht Client Y, die Datei zu öffnen. Die Ansicht des Servers für die Datei ist, dass client X geöffnet ist, obwohl sie von der Anwendung auf Client X geschlossen wurde. Daher sendet der Server eine Nachricht, die die opportunistische Sperre an Client X bricht. Client X sendet jetzt die Schließ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 keine weiteren Übertragungen zum oder vom Server für diese Datei ausgeführt werden. Client Y beginnt wie in Ereignis 15 üblich mit Datenübertragungen.

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 erteilt wird, sind alle Dateidaten gültig, die der Client zwischengespeichert hat, trotz der zwischengespeicherten Vorgänge zum Öffnen und Schließen der Anwendung. Nachdem die opportunistische Sperre jedoch unterbrochen wurde, können zwischengespeicherte Daten nicht als gültig betrachtet werden.

Opportunistische Sperre filtern

Das folgende Diagramm zeigt eine Ansicht des Netzwerkdatenverkehrs einer opportunistischen Filtersperre. Die Pfeile geben die Richtung der Datenverschiebung an, falls vorhanden.

Ereignis	Client X	Server	Client Y
1	Öffnet die Datei ohne Zugriffsrechte .>
2		<== Öffnet die Datei.
3	Filtersperre für Anforderungen.>
4		<== Gewährt Sperre
5	Öffnet die Datei zum Lesen von .>
6		<== Öffnet die Datei erneut.
7	Liest Daten mithilfe des Lesehandles .>
8		<== Sendet Daten.
9		<== Sendet Daten.
10		<== Sendet Daten.
11			<== Öffnet die Datei.
12		Öffnet die Datei .>
13			<== Anforderungsfiltersperre
14		Filtersperre verweigern.>
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(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 die Datei dann erneut zum Lesen in Ereignis 5, auf das 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 dem Client voraus und sendet die Daten über das Netzwerk, obwohl der Client sie nicht angefordert hat. Der Client speichert die Daten zwischen. Im Fall 10 erwartet der Server auch eine zukünftige Anforderung für Daten und sendet einen weiteren Teil der Datei für den Client zum Zwischenspeichern.

In den Ereignissen 11 und 12 öffnet ein anderer Client, Y, die Datei. Client Y fordert auch eine opportunistische Filtersperre an. Im Fall 14 verweigert der Server dies. Im Fall 15 fordert Client Y Daten an, die der Server im Ereignis 16 sendet. Nichts 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. Da der Server die Daten jedoch bereits gesendet hat und der Client sie zwischengespeichert hat, durchquert kein Datenverkehr das Netzwerk.

In diesem Beispiel versucht Client X nie, alle Daten in der Datei zu lesen, sodass der durch die Ereignisse 9 und 10 angegebene Lesevorlesevorgang "verschwendet" ist; Das heißt, die Daten werden nie tatsächlich verwendet. Dies ist ein akzeptabler Verlust, da die Anwendung durch Lesezugriff beschleunigt wurde.

Im Fall 18 schließt Client X die Datei. Die Netzwerkumleitung des Clients verlässt die zwischengespeicherten Daten. Der Server schließt die Datei.