Verwalten von Dateisperren

Azure Files ermöglicht den Zugriff auf Clouddateifreigaben über die folgenden Protokolle:

• Server Message Block (SMB)
• Network File System (NFS)
• FileREST (HTTPS)

In diesem Thema wird beschrieben, wie Sie Die Interaktionen mit Dateisperren zwischen SMB und FileREST verwalten. NFS-Dateifreigaben weisen unterschiedliche Sperrsemantik auf und unterstützen eine Teilmenge der FileREST-APIs. Dieses Thema gilt nicht für NFS-Dateifreigaben.

SMB-Dateisperre

SMB-Clients, die Dateifreigaben einbinden, können Dateisystemsperrmechanismen verwenden, um den Zugriff auf freigegebene Dateien zu verwalten. Dazu zählen unter anderem folgende Einstellungen:

• Die gesamte Freigabe des Dateizugriffs zum Lesen, Schreiben und Löschen.
• Bytebereichssperren zum Verwalten des Lese- und Schreibzugriffs auf Bereiche in einer einzelnen Datei.

Wenn ein SMB-Client eine Datei öffnet, gibt er sowohl den Dateizugriff als auch den Freigabemodus an. Die folgenden Dateizugriffsoptionen werden normalerweise von SMB-Clients verwendet, obwohl alle Kombinationen zulässig sind:

• Nichts: Öffnet eine Datei nur für den Abfrageattributezugriff.
• Lesen: Öffnet eine Datei nur für den Lesezugriff.
• Schreiben: Öffnet eine Datei nur für Schreibzugriff.
• Lese-/Schreibzugriff: Öffnet eine Datei mit Lese-/Schreibberechtigungen.
• Löschen: Öffnet eine Datei nur zum Löschen des Zugriffs.

Die folgende Dateifreigabemodi werden in der Regel von SMB-Clients verwendet:

• Nichts: Lehnt die Freigabe der aktuellen Datei ab. Jede Anforderung zum Öffnen der Datei mit Lese-, Schreib- oder Löschzugriff schlägt fehl, bis die Datei geschlossen wird.
• Freigegebener Lesevorgang: Ermöglicht das nachfolgende Öffnen der Datei zum Lesen. Wenn dieses Flag nicht angegeben ist, schlägt jede Anforderung zum Öffnen der Datei zum Lesen fehl, bis die Datei geschlossen wird.
• Freigegebener Schreibvorgang: Ermöglicht das nachfolgende Öffnen der Datei zum Schreiben. Wenn dieses Flag nicht angegeben wird, schlägt jede Anforderung zum Öffnen der Datei zum Schreiben fehl, bis die Datei geschlossen wird.
• Freigegebener Lese-/Schreibzugriff: Ermöglicht das nachfolgende Öffnen der Datei zum Lesen oder Schreiben. Wenn dieses Flag nicht angegeben ist, schlägt jede Anforderung zum Öffnen der Datei zum Lesen oder Schreiben fehl, bis die Datei geschlossen wird.
• Freigegebenes Löschen: Ermöglicht das nachfolgende Löschen einer Datei. Wenn dieses Flag nicht angegeben ist, schlägt jede Anforderung zum Löschen der Datei fehl, bis die Datei geschlossen wird.

Beispiele für offene SMB-Clientdateien

Sehen Sie sich die folgenden Beispiele für das Öffnen von Dateien an:

• Datei wird ohne Freigabeverletzung geöffnet

  • Client A öffnet die Datei mit FileAccess.Read und FileShare.Write (verweigert nachfolgendes Lesen/Löschen während des Öffnens).
  • Client B öffnet dann die Datei mit FileAccess.Write mit FileShare.Read (verweigert das nachfolgende Schreiben/Löschen während des Öffnens).
  • Ergebnis: Dies ist zulässig, da es keinen Konflikt zwischen Dateizugriff und Dateifreigabemodi gibt.

• Freigabeverletzung aufgrund des Dateizugriffs

  • Client A öffnet die Datei mit FileAccess.Write und FileShare.Read (verweigert nachfolgendes Schreiben/Löschen beim Öffnen).
  • Client B öffnet dann die Datei mit FileAccess.Write fileShare.Write (verweigert nachfolgendes Lesen/Löschen beim Öffnen).
  • Ergebnis: Client B stößt auf eine Freigabeverletzung. Der Client hat einen Dateizugriff angegeben, der durch den zuvor von Client A angegebenen Freigabemodus verweigert wird.

• Freigabeverletzung aufgrund des Freigabemodus

  • Client A öffnet die Datei mit FileAccess.Write und FileShare.Write (verweigert nachfolgendes Lesen/Löschen während des Öffnens).
  • Client B öffnet dann die Datei mit FileAccess.Write mit FileShare.Read (verweigert das nachfolgende Schreiben/Löschen während des Öffnens).
  • Ergebnis: Client B stößt auf eine Freigabeverletzung. Der Client hat einen Freigabemodus angegeben, der den Schreibzugriff auf eine Datei verweigert, die noch für den Schreibzugriff geöffnet ist.

FileREST-Dateizugriff

Wenn Sie einen FileREST-Vorgang ausführen, muss dieser Vorgang den Freigabemodus berücksichtigen, der für jede Datei angegeben ist, die auf einem SMB-Client geöffnet wird. Verwenden Sie den folgenden Dateizugriffsmodus, um zu bestimmen, ob der Vorgang abgeschlossen werden kann:

FileREST-Vorgang	Dateizugriffsäquivalent
Auflisten von Verzeichnissen und Dateien	N/V.
Datei erstellen	Schreiben, löschen.
Get File	Lesen.
Dateieigenschaften festlegen	Schreiben.
Dateieigenschaften abrufen	N/V.
Set File Metadata	Schreiben.
Dateimetadaten abrufen	N/V.
Löschen einer Datei	Löschen
Put Range	Schreiben.
List Ranges	Lesen.
Leasedatei	Schreiben, Löschen und Freigegebenes Lesen für die Dauer der Lease.

Listenverzeichnisse und Dateien, Dateieigenschaften abrufen und Dateimetadaten abrufen funktionieren nicht für Dateiinhalte. Für diese Vorgänge ist kein Lesezugriff auf die Datei erforderlich (d. a. d. a. diese Vorgänge sind erfolgreich, auch wenn ein SMB-Client die Datei für exklusiven Lesezugriff geöffnet hat).

Im Folgenden sind Beispiele für FileREST-Anforderungen aufgeführt, die mit den SMB-Freigabemodi interagieren:

• FileREST Get File Sharing-Verletzung

  • Der SMB-Client öffnet die Datei mit FileAccess.Read und FileShare.Write (verweigert nachfolgendes Lesen/Löschen während des Öffnens).
  • Der REST-Client führt dann einen Vorgang "Datei abrufen" für die Datei aus (und verwendet FileAccess.Read dabei, wie in der vorherigen Tabelle angegeben).
  • Ergebnis: Die Anforderung des REST-Clients schlägt mit status Code 409 (Konflikt) und Fehlercode SharingViolationfehl. Der SMB-Client hat die Datei weiterhin geöffnet und verweigert den Lese-/Löschzugriff.

• FileREST Put Range-Freigabeverletzung

  • Der SMB-Client öffnet die Datei mit FileAccess.Write und FileShare.Read (verweigert das nachfolgende Schreiben/Löschen während des Öffnens).
  • Der REST-Client führt dann einen Put Range-Vorgang für die Datei aus (dabei wie FileAccess.Write in der vorherigen Tabelle angegeben).
  • Ergebnis: Die Anforderung des REST-Clients schlägt mit status Code 409 (Konflikt) und Fehlercode SharingViolationfehl. Der SMB-Client hat die Datei weiterhin geöffnet und verweigert den Schreib-/Löschzugriff.

Der nächste Abschnitt enthält eine umfassende Tabelle mit Szenarien zur Verletzung von FileREST-API-Verstößen.

Auswirkungen des SMB-Clientfreigabemodus auf FileREST

Abhängig vom Freigabemodus, den Sie angeben, wenn ein SMB-Client eine Datei öffnet, kann FileREST status Code 409 (Konflikt) mit Fehlercode SharingViolationzurückgeben. In der folgenden Tabelle sind eine Reihe von Szenarien aufgeführt.

Dateifreigabemodus für den SMB-Client	Fehler bei FileREST-Vorgängen mit einer Freigabeverletzung
None (Deny Read, Write, Delete)	Die folgenden Lese-, Schreib-, Lease- und Löschvorgänge für die Datei schlagen fehl: Erstellen der Datei Get File Set File Properties Set File Metadata Datei löschen Put Range List Ranges Leasedatei
Shared Read Deny Write, Delete)	Die folgenden Schreib-, Lease- und Löschvorgänge für die Datei schlagen fehl: Erstellen der Datei Set File Properties Set File Metadata Datei löschen Put Range Leasedatei
Shared Write (Deny Read, Delete)	Die folgenden Lese-, Lease- und Löschvorgänge für die Datei schlagen fehl: Erstellen der Datei Get File Datei löschen List Ranges Leasedatei
Shared Delete (Deny Read, Write)	Die folgenden Lese-, Schreib- und Leasevorgänge für die Datei schlagen fehl: Erstellen der Datei Get File Set File Properties Set File Metadata Put Range List Ranges Datei löschen Leasedatei
Shared Read/Write (Deny Delete)	Die folgenden Lease- und Löschvorgänge für die Datei schlagen fehl: Erstellen der Datei Datei löschen Leasedatei
Shared Read/Delete (Deny Write)	Die folgenden Schreib-, Lease- und Löschvorgänge für die Datei schlagen fehl: Erstellen der Datei Set File Properties Set File Metadata Put Range Datei löschen Leasedatei
Shared Write/Delete (Deny Read)	Die folgenden Lese- und Leasevorgänge für die Datei schlagen fehl: Get File List Ranges Datei löschen Leasedatei
Shared Read/Write/Delete (Deny Nothing)	Datei löschen

Azure Files gibt Nur dann Freigabeverletzungen zurück, wenn Dateien auf SMB-Clients geöffnet sind. Damit ein FileREST-Dateilöschvorgang erfolgreich ist, dürfen keine SMB-Clients mit für diese Datei geöffneten Handles vorhanden sein. Weitere Informationen finden Sie unter Dateilöschvorgang und Interaktion zwischen opportunistischen FileREST- und SMB-Sperren.

Auswirkungen auf die SMB-Dateisperrung auf die FileREST-Leasedatei-API

Abhängig von den Dateizugriffsoptionen, die Sie angeben, wenn ein SMB-Client eine Datei öffnet, ist es möglich, dass die FileREST-Leasedatei-API status Code 409 (Konflikt) mit dem Fehlercode SharingViolationzurückgibt. Die folgende Tabelle enthält weitere Informationen:

SMB-Clientdateizugriffsoption	Abrufen einer Lease für eine Datei ohne aktive Lease mit der Leasedatei-API
Keine	Ist erfolgreich
Lesen	Ist erfolgreich
Schreiben	Fehler aufgrund von SharingViolation
Löschen	Fehler aufgrund von SharingViolation
Lesen|Schreiben	Fehler aufgrund von SharingViolation
Lesen|Löschen	Fehler aufgrund von SharingViolation
Schreiben|Löschen	Fehler aufgrund von SharingViolation
Lesen|Schreiben|Löschen	Fehler aufgrund von SharingViolation

Azure Files gibt Nur dann Freigabeverletzungen zurück, wenn Dateien auf SMB-Clients geöffnet sind. Beachten Sie, dass für einen erfolgreichen FileREST-Leasedateivorgang keine SMB-Clients mit schreib- oder delete-Handles für diese Datei geöffnet sein können. Weitere Informationen finden Sie unter Lease File operation and Interaction between FileREST and SMB opportunistic locks.

Auswirkungen der FileREST-Leasedatei auf SMB-Dateisperren

Eine Lease für eine Datei bietet exklusiven Schreib- und Löschzugriff auf die Datei. Wenn ein SMB-Client eine Datei öffnet, muss er die Sperre für jede Datei respektieren, die vom FileREST-Leasedateivorgang geleast wird. Anhand der folgenden Tabelle können Sie bestimmen, ob der Vorgang zum Öffnen der SMB-Datei abgeschlossen werden kann:

FileREST-Dateileasingstatus	Fehler bei SMB-Vorgängen mit einem Freigabeverstoß
Geleast	SMB-Clients, die die Datei mit dem folgenden Dateizugriff öffnen, schlagen fehl: FileAccess.Write FileAccess.Delete FileAccess.Read|FileAccess.Write FileAccess.Write|FileAccess.Delete FileAccess.Read|FileAccess.Write|FileAccess.Delete
Verfügbar	Keine
Beschädigt	Keine

Auswirkungen auf SMB-Löschvorgänge auf FileREST

Wenn ein SMB-Client eine Datei zum Löschen öffnet, markiert er die Datei als ausstehendes Löschen, bis alle anderen geöffneten SMB-Clienthandles für diese Datei geschlossen werden. Während eine Datei als ausstehendes Löschen markiert ist, gibt jeder FileREST-Vorgang für diese Datei status Code 409 (Konflikt) mit dem Fehlercode SMBDeletePendingzurück. Der Statuscode 404 (Nicht gefunden) wird nicht zurückgegeben, da der SMB-Client das Flag zum ausstehenden Löschen vor dem Schließen der Datei entfernen kann. Mit anderen Worten, der Statuscode 404 (Nicht gefunden) ist nur zu erwarten, wenn die Datei entfernt wurde.

Während sich eine Datei in einem SMB-Löschstatus befindet, wird sie nicht in die List Files Ergebnisse einbezogen.

Beachten Sie auch, dass die FileREST Delete File - und Delete Directory -Vorgänge atomar committet werden und nicht zu einem ausstehenden Löschstatus führen.

Auswirkungen auf Dateiattribute auf FileREST

SMB-Clients können Dateiattribute lesen und festlegen, so z. B.:

• Archivieren
• Schreibgeschützt
• Ausgeblendet
• System

Wenn eine Datei oder ein Verzeichnis als schreibgeschützt gekennzeichnet ist, schlägt jeder FileREST-Vorgang, der versucht, in die Datei zu schreiben, mit status Code 412 (Vorbedingung fehlgeschlagen) und dem Fehlercode ReadOnlyAttributefehl. Dazu zählen die Operationen:

• Create File
• Set File Properties
• Set File Metadata
• Put Range

Diese Dateiattribute können nicht festgelegt oder von REST-Clients gelesen werden. Nachdem eine Datei schreibgeschützt wurde, können REST-Clients erst dann in die Datei schreiben, wenn der SMB-Client das schreibgeschützte Attribut entfernt.

Interaktion zwischen opportunistischen FileREST- und SMB-Sperren

Opportunistische SMB-Sperren (Oplock) sind ein Mechanismus für das Zwischenspeichern, den SMB-Clients anfordern, um die Leistung zu verbessern und Netzwerkübertragungen zu reduzieren. Ein SMB-Client kann den aktuellen Status einer bestimmten Datei oder eines bestimmten Verzeichnisses zwischenspeichern. Es gibt mehrere Typen opportunistischer Sperren, die als SMB-Leasetypen bezeichnet werden:

• Lesen (R): Der SMB-Client kann aus dem lokalen Cache lesen.
• Schreiben (W): Der SMB-Client kann lokal schreiben, ohne dass die Daten zurück in die Azure-Dateifreigabe geleert werden müssen.
• Handle (H): Der SMB-Client muss die Azure-Dateifreigabe nicht sofort benachrichtigen, wenn ein Handle geschlossen wird. Dieser Sperrtyp ist nützlich, wenn eine Anwendung weiterhin Dateien mit demselben Zugriffs- und Freigabemodus öffnet und schließt.

Diese Leasetypen sind unabhängig vom angegebenen Zugriffs- und Freigabemodus. In der Regel versucht ein SMB-Client, alle Leasetypen abzurufen, wenn er ein neues Handle für eine Datei öffnet, unabhängig vom Zugriffs- und Freigabemodus.

Abhängig vom FileREST-Vorgang namens müssen Sie möglicherweise anfordern, eine vorhandene opportunistische Sperre zu unterbrechen. Im Falle eines Schreibvorgangs muss der SMB-Client zwischengespeicherte Änderungen an der Azure-Dateifreigabe leeren. Hier nun einige Fälle, in denen jede Art von opportunistischer Sperre unterbrochen werden muss:

• Ein Lesevorgang (R) muss immer dann unterbrochen werden, wenn ein Schreibvorgang ausgegeben wird, z Put Range. B. .

• Ein Schreibvorgang (W) muss immer dann unterbrochen werden, wenn ein Lesevorgang ausgegeben wird, z Get File. B. .

• Ein Handle(H)-Oplock muss immer dann unterbrochen werden, wenn ein Client einen Löschvorgang ausgibt. Azure Files erfordert, dass keine Handles geöffnet werden können, wenn ein Löschvorgang erfolgreich sein soll.

  Handle-Oplocks werden auch dann unterbrochen, wenn ein FileREST-Vorgang mit einem vorhandenen SMB-Handle auf einen Freigabeverstoß stößt. Dies geschieht, um zu überprüfen, ob die Handles weiterhin von einer Anwendung geöffnet werden, die auf den Clients ausgeführt wird.

Das Unterbrechen des Oplocks erfordert möglicherweise das Leeren von zwischengespeicherten SMB-Clientänderungen, was zu Verzögerungen bei der Antwortzeit des Vorgangs führen kann. Das Leeren kann auch dazu führen, dass der Vorgang mit status Code 408 (Anforderungstimeout) und dem Fehlercode fehlschlägtClientCacheFlushDelay.

In den folgenden Abschnitten werden Szenarien erläutert, in denen Oplocks unterbrochen werden.

Ein Oplock-Break und eine SMB-Clientleerung sind erforderlich, und der REST-Client kommt zu einer Verzögerung.

Sehen Sie sich das folgende Beispiel an:

1. Der SMB-Client öffnet eine Datei, erhält eine opportunistische Sperre vom Typ "RWH" und schreibt Daten lokal.

2. Der REST-Client sendet eine Get File Anforderung.

   • Die Azure-Dateifreigabe unterbricht den Schreibvorgang (W), sodass der Client einen RH-Oplock belässt.
   • Der SMB-Client leert seine zwischengespeicherten Daten für die Azure-Dateifreigabe und bestätigt den Oplock-Umbruch.
   • Die Azure-Dateifreigabe verarbeitet die Get File Anforderung und antwortet mit den angeforderten Daten.

In diesem Beispiel kommt es beim REST-Client zu Verzögerungen. Diese Situation wird durch den Oplock-Umbruch und die Zeit verursacht, die der SMB-Client zum Leeren seiner Daten für die Azure-Dateifreigabe benötigte.

Bei nachfolgenden Aufrufen von Get File treten keine zusätzlichen Verzögerungen auf, da der Schreibvorgang (W) bereits unterbrochen wurde.

Eine Unterbrechung einer opportunistischen Sperre ist erforderlich, aber der REST-Client erleidet keine Verzögerung.

Sehen Sie sich das folgende Beispiel an:

1. Der SMB-Client hat eine opportunistischen Sperre vom Typ "RH" aktiviert.

2. Der REST-Client sendet eine Put Range Anforderung.

   • Die Azure-Dateifreigabe sendet eine Oplock-Unterbrechungsanforderung an den SMB-Client und wartet nicht auf eine Antwort.
   • Die Azure-Dateifreigabe verarbeitet die Put Range Anforderung.

In diesem Beispiel ist der Oplock-Umbruch erforderlich, aber für die Put Range Anforderung treten keine zusätzlichen Verzögerungen auf. Beim Unterbrechen des Lese-Oplocks ist keine Antwort erforderlich.

Azure Files Verhalten

In der folgenden Tabelle ist das Verhalten der Azure Files für jeden FileREST-Vorgang zusammengefasst. Dieses Verhalten basiert auf dem Oplockzustand des SMB-Clients, der bereits ein Handle für dieselbe Datei abgerufen hat. Darüber hinaus wird beim Verhalten davon ausgegangen, dass die SMB-Verarbeitung von Zugriff und Freigabe keinen Konflikt mit dem FileREST-Vorgang verursacht.

Wenn ein Konflikt vorliegt, wird die opportunistische Handlesperre ebenfalls unterbrochen, um sicherzustellen, dass der Handle auf dem Client weiter geöffnet ist. Bei einem blockierenden Oplock-Umbruch müssen Azure Files auf eine Bestätigung warten, dass die Unterbrechung erfolgreich war. Bei einem nicht blockierenden Oplock-Umbruch muss Azure Files nicht warten.

FileREST-Vorgang	Aktuelle Oplock-Typen	Oplock-Unterbrechung ausgeführt	Resultierender Oplock
Get File	RWH	Ja (Blockieren)	RH
Get File	RH	Nein	RH
Get File	RW	Ja (Blockieren)	R
Get File Properties	RWH	Ja (Blockieren)	RH
Get File Properties	RH	Nein	RH
Get File Properties	RW	Ja (Blockieren)	R
List Ranges	RWH	Ja (Blockieren)	RH
List Ranges	RH	Nein	RH
List Ranges	RW	Ja (Blockieren)	R
Dateimetadaten abrufen	RWH	Ja (Blockieren)	RH
Dateimetadaten abrufen	RH	Nein	RH
Dateimetadaten abrufen	RW	Ja (Blockieren)	R
Auflisten von Dateien	RWH	Nein	RWH
Auflisten von Dateien	RH	Nein	RH
Auflisten von Dateien	RW	Nein	RW
Put Range	RWH	Ja (Blockieren)	Keine
Put Range	RH	Ja (Nicht blockierend)	Keine
Put Range	RW	Ja (Blockieren)	Keine
Set File Properties	RWH	Ja (Blockieren)	Keine
Set File Properties	RH	Ja (Nicht blockierend)	Keine
Set File Properties	RW	Ja (Blockieren)	Keine
Set File Metadata	RWH	Ja (Blockieren)	Keine
Set File Metadata	RH	Ja (Nicht blockierend)	Keine
Set File Metadata	RW	Ja (Blockieren)	Keine
Datei löschen	RWH	Ja (Blockieren)	RW
Datei löschen	RH	Ja (Blockieren)	R
Datei löschen	RW	Nein	RW

Für den Fall, dass ein blockierenden Oplock-Umbruch erforderlich ist, schlägt der FileREST-Vorgang unter bestimmten Bedingungen fehl. Wenn die Unterbrechung innerhalb des angegebenen Anforderungstimeouts nicht erfolgreich ist oder innerhalb von 30 Sekunden (je nachdem, was zuerst abgeschlossen wird), gibt der Dienst status Code 408 (Anforderungstimeout) und den Fehlercode ClientCacheFlushDelayzurück.

Die Delete File Anforderung erfordert auch das Unterbrechen der Oplock-Handle(H)-Lease. Das Unterbrechen des Handle stellt sicher, dass keine Dateihandles noch von einer SMB-Clientanwendung geöffnet werden, wenn ein REST-Client aufruft Delete File. Wenn ein Freigabeverstoß vorliegt, schlägt die Anforderung mit status Code 409 (Konflikt) und dem Fehlercode SharingViolationfehl.

Weitere Informationen

Azure Files Konzepte