Gérer les verrous de fichiers

Azure Files permet d’accéder aux partages de fichiers cloud via les protocoles suivants :

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

Cette rubrique explique comment gérer les interactions de verrouillage de fichiers entre SMB et FileREST. Les partages de fichiers NFS ont une sémantique de verrouillage différente et prennent en charge un sous-ensemble des API FileREST. Cette rubrique ne s’applique pas aux partages de fichiers NFS.

Verrouillage de fichiers SMB

Les clients SMB qui montent des partages de fichiers peuvent utiliser des mécanismes de verrouillage du système de fichiers pour gérer l’accès aux fichiers partagés. Il s’agit notamment des paramètres suivants :

• partage de l'accès à la totalité du fichier pour la lecture, l'écriture et la suppression ;
• verrouillages de plages d'octets pour gérer l'accès en lecture et en écriture à des zones à l'intérieur d'un fichier.

Lorsqu’un client SMB ouvre un fichier, il spécifie à la fois l’accès au fichier et le mode de partage. Les options d’accès aux fichiers suivantes sont généralement utilisées par les clients SMB, bien que toutes les combinaisons soient autorisées :

• Aucun: Ouvre un fichier pour l’accès à l’attribut de requête uniquement.
• Lire: Ouvre un fichier pour l’accès en lecture uniquement.
• Écrire: Ouvre un fichier pour l’accès en écriture uniquement.
• Lecture/écriture : Ouvre un fichier avec des autorisations de lecture/écriture.
• Supprimer: Ouvre un fichier pour supprimer l’accès uniquement.

Les clients SMB utilisent généralement les modes de partage de fichiers suivants :

• Aucun: Refuse le partage du fichier actif. Toute demande d’ouverture du fichier avec un accès en lecture, écriture ou suppression échoue, jusqu’à ce que le fichier soit fermé.
• Lecture partagée : Autorise l’ouverture ultérieure du fichier pour la lecture. Si cet indicateur n’est pas spécifié, toute demande d’ouverture du fichier pour lecture échoue, jusqu’à ce que le fichier soit fermé.
• Écriture partagée : Autorise l’ouverture ultérieure du fichier pour l’écriture. Si cet indicateur n’est pas spécifié, toute demande d’ouverture du fichier pour écriture échoue, jusqu’à ce que le fichier soit fermé.
• Lecture/écriture partagée : Autorise l’ouverture ultérieure du fichier pour la lecture ou l’écriture. Si cet indicateur n’est pas spécifié, toute demande d’ouverture du fichier à des fins de lecture ou d’écriture échoue, jusqu’à ce que le fichier soit fermé.
• Suppression partagée : Permet la suppression ultérieure d’un fichier. Si cet indicateur n’est pas spécifié, toute demande de suppression du fichier échoue tant que le fichier n’est pas fermé.

Exemples de fichiers ouverts du client SMB

Examinez les exemples suivants d'ouverture de fichier :

• Le fichier s’ouvre sans violation de partage

  • Le client A ouvre le fichier avec FileAccess.Read et FileShare.Write (refuse la lecture/suppression ultérieure lors de l’ouverture).
  • Le client B ouvre ensuite le fichier avec FileAccess.Write avec FileShare.Read (refuse l’écriture/la suppression ultérieure lors de l’ouverture).
  • Résultat: Cela est autorisé, car il n’y a aucun conflit entre l’accès aux fichiers et les modes de partage de fichiers.

• Violation de partage en raison de l’accès aux fichiers

  • Le client A ouvre le fichier avec FileAccess.Write et FileShare.Read (refuse l’écriture/la suppression ultérieure lors de l’ouverture).
  • Le client B ouvre ensuite le fichier avec FileAccess.Write avec FileShare.Write (refuse la lecture/suppression ultérieure lors de l’ouverture).
  • Résultat: Le client B rencontre une violation de partage. Le client a spécifié un accès aux fichiers qui est refusé par le mode de partage spécifié précédemment par le client A.

• Violation de partage en raison du mode de partage

  • Le client A ouvre le fichier avec FileAccess.Write et FileShare.Write (refuse la lecture/suppression ultérieure lors de l’ouverture).
  • Le client B ouvre ensuite le fichier avec FileAccess.Write avec FileShare.Read (refuse l’écriture/la suppression ultérieure lors de l’ouverture).
  • Résultat: Le client B rencontre une violation de partage. Le client a spécifié un mode de partage qui refuse l’accès en écriture à un fichier qui est toujours ouvert pour l’accès en écriture.

Accès aux fichiers FileREST

Lorsque vous effectuez une opération FileREST, cette opération doit respecter le mode de partage spécifié pour tout fichier ouvert sur un client SMB. Utilisez le mode d’accès aux fichiers suivant pour déterminer si l’opération peut être terminée :

Répertorier les répertoires et les fichiers, Obtenir les propriétés de fichier et Obtenir les métadonnées de fichier ne fonctionnent pas sur le contenu du fichier. Ces opérations ne nécessitent pas d’accès en lecture au fichier (autrement dit, ces opérations réussissent même si un client SMB a le fichier ouvert pour un accès en lecture exclusif).

Voici des exemples de requêtes FileREST qui interagissent avec les modes de partage SMB :

• FichierREST Obtenir une violation de partage de fichiers

  • Le client SMB ouvre le fichier avec FileAccess.Read et FileShare.Write (refuse la lecture/la suppression ultérieure lors de l’ouverture).
  • Le client REST effectue ensuite une opération Get File sur le fichier (en utilisant FileAccess.Read ainsi comme spécifié dans le tableau précédent).
  • Résultat: La demande du client REST échoue avec status code 409 (Conflit) et le code SharingViolationd’erreur . Le client SMB a toujours le fichier ouvert et refuse l’accès en lecture/suppression.

• Violation du partage de plage FileREST Put

  • Le client SMB ouvre le fichier avec FileAccess.Write et FileShare.Read (refuse l’écriture/la suppression ultérieure lors de l’ouverture).
  • Le client REST effectue ensuite une opération Put Range sur le fichier (en utilisant FileAccess.Write ainsi comme spécifié dans le tableau précédent).
  • Résultat: La demande du client REST échoue avec status code 409 (Conflit) et le code SharingViolationd’erreur . Le client SMB a toujours le fichier ouvert et refuse l’accès Écriture/Suppression.

La section suivante inclut un tableau complet des scénarios de violation de l’API FileREST.

Implications du mode de partage du client SMB sur FileREST

Selon le mode de partage que vous spécifiez lorsqu’un client SMB ouvre un fichier, il est possible pour FileREST de retourner status code 409 (Conflit) avec le code SharingViolationd’erreur . Le tableau suivant répertorie un certain nombre de scénarios.

Azure Files retourne les violations de partage uniquement lorsque les fichiers sont ouverts sur les clients SMB. Pour qu’une opération de suppression de fichier FileREST réussisse, il ne peut y avoir de clients SMB avec des handles ouverts sur ce fichier. Pour plus d’informations, consultez l’opération Supprimer un fichier et Interaction entre les verrous opportunistes FileREST et SMB.

Implications du verrouillage de fichiers SMB sur l’API FileREST Lease File

Selon les options d’accès aux fichiers que vous spécifiez lorsqu’un client SMB ouvre un fichier, il est possible que l’API Fichier de bail FileREST retourne status code 409 (Conflit), avec le code SharingViolationd’erreur . Le tableau suivant fournit des informations supplémentaires :

Azure Files retourne les violations de partage uniquement lorsque les fichiers sont ouverts sur les clients SMB. Notez que pour qu’une opération FileREST Lease File réussisse, il ne peut y avoir de clients SMB avec des handles d’écriture ou de suppression ouverts sur ce fichier. Pour plus d’informations, consultez l’opération De fichier de bail et Interaction entre les verrous opportunistes FileREST et SMB.

Implications du fichier de bail FileREST pour le verrouillage de fichiers SMB

Un bail sur un fichier fournit un accès exclusif en écriture et en suppression au fichier. Lorsqu’un client SMB ouvre un fichier, il doit respecter le verrou de tout fichier loué par l’opération FileREST Lease File. Vous pouvez utiliser le tableau suivant pour déterminer si l’opération d’ouverture de fichier SMB peut être effectuée :

Implications de la suppression SMB sur FileREST

Lorsqu’un client SMB ouvre un fichier pour suppression, il marque le fichier comme étant en attente de suppression, jusqu’à ce que tous les autres handles ouverts du client SMB sur ce fichier soient fermés. Lorsqu’un fichier est marqué comme étant en attente de suppression, toute opération FileREST sur ce fichier retourne status code 409 (Conflit), avec le code SMBDeletePendingd’erreur . Le code d’état 404 (Introuvable) n’est pas retourné, car il est possible pour le client SMB de supprimer l’indicateur de suppression en attente avant de fermer le fichier. En d'autres termes, le code d'état 404 (Introuvable) ne peut être renvoyé que si le fichier a été supprimé.

Lorsqu’un fichier est dans un état de suppression en attente de suppression SMB, il n’est pas inclus dans les List Files résultats.

Notez également que les opérations FileREST Delete File et Delete Directory sont validées de manière atomique et n’entraînent pas l’état de suppression en attente.

Implications d’attribut de fichier sur FileREST

Les clients SMB peuvent lire et définir les attributs de fichier suivants :

• Archive
• Lecture seule
• Hidden
• Système

Si un fichier ou un répertoire est marqué en lecture seule, toute opération FileREST qui tente d’écrire dans le fichier échoue avec status code 412 (échec de la condition préalable) et le code ReadOnlyAttributed’erreur . Ces opérations comprennent :

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

Ces attributs de fichier ne peuvent pas être définis ou lus à partir de clients REST. Une fois qu’un fichier est en lecture seule, les clients REST ne peuvent pas écrire dans le fichier tant que le client SMB n’a pas supprimé l’attribut en lecture seule.

Interaction entre les verrous opportunistes FileREST et SMB

Un verrou opportuniste SMB (oplock) est un mécanisme de mise en cache qu'un client SMB demande pour améliorer les performances et réduire les transferts réseau. Un client SMB peut mettre en cache l’état le plus récent d’un fichier ou d’un répertoire particulier. Il existe plusieurs types de verrous opportunistes, appelés types de baux SMB :

• Lecture (R) : le client SMB peut lire à partir du cache local.
• Écriture (W) : le client SMB peut écrire localement, sans avoir à vider les données dans le partage de fichiers Azure.
• Handle (H) : le client SMB n’est pas tenu d’avertir immédiatement le partage de fichiers Azure lorsqu’un handle est fermé. Ce type de verrou est utile lorsqu’une application continue d’ouvrir et de fermer des fichiers avec le même mode d’accès et de partage.

Ces types de bail sont indépendants du mode d’accès et de partage spécifié. En règle générale, un client SMB tente d’acquérir tous les types de bail chaque fois qu’il ouvre un nouveau handle sur un fichier, quel que soit le mode d’accès et de partage.

Selon l’opération FileREST appelée, vous devrez peut-être demander à rompre un verrou opportuniste existant. Dans le cas d’un oplock d’écriture, le client SMB doit vider les modifications mises en cache dans le partage de fichiers Azure. Voici quelques cas où chaque type de verrou oplock doit être rompu :

• Un oplock en lecture (R) doit être rompu chaque fois qu’une opération d’écriture est émise, telle que Put Range.

• Un oplock d’écriture (W) doit être rompu chaque fois qu’une opération de lecture est émise, telle que Get File.

• Un oplock handle (H) doit être rompu chaque fois qu’un client émet une opération de suppression. Azure Files nécessite qu’aucun handle ne puisse être ouvert si une opération de suppression doit réussir.

  Les oplocks de handle sont également rompus lorsqu’une opération FileREST fait face à une violation de partage avec un handle SMB existant. Cela se produit pour vérifier que les handles sont toujours ouverts par une application en cours d’exécution sur les clients.

La rupture de l’oplock peut nécessiter le vidage des modifications du client SMB mis en cache, ce qui peut entraîner des retards dans le temps de réponse de l’opération. Le vidage peut également entraîner l’échec de l’opération avec status code 408 (délai d’expiration de la demande) et le code ClientCacheFlushDelayd’erreur .

Les sections suivantes décrivent les scénarios où les verrous oplocks sont rompus.

Un arrêt d’opération de verrouillage et un vidage du client SMB sont requis, et le client REST subit un retard

Prenons l’exemple suivant :

1. Le client ouvre un fichier, acquiert un verrou oplock RWH, et écrit les données localement.

2. Le client REST envoie une Get File requête.

   • Le partage de fichiers Azure interrompt le verrouillage d’opération d’écriture (W), laissant le client avec un oplock RH.
   • Le client SMB vide ses données mises en cache sur le partage de fichiers Azure et reconnaît l’arrêt du blocage d’opération.
   • Le partage de fichiers Azure traite la Get File demande et répond avec les données demandées.

Dans cet exemple, le client REST subit des retards. Cette situation est due au blocage d’opération et au temps nécessaire au vidage de ses données par le client SMB sur le partage de fichiers Azure.

Les appels ultérieurs à Get File ne rencontrent pas de retards supplémentaires, car le verrou d’opération d’écriture (W) a déjà été rompu.

Une rupture de verrou oplock est requise, mais le client REST ne subit pas de retard

Prenons l’exemple suivant :

1. Le client SMB a acquis un verrou oplock RH.

2. Le client REST envoie une Put Range requête.

   • Le partage de fichiers Azure envoie une demande d’arrêt d’opération au client SMB et n’attend pas de réponse.
   • Le partage de fichiers Azure traite la Put Range demande.

Dans cet exemple, l’arrêt du blocage d’opération est requis, mais la Put Range demande ne connaît pas de retards supplémentaires. Une réponse n’est pas nécessaire lors de la rupture du verrouillage d’opération de lecture.

Azure Files comportement

Le tableau suivant récapitule le comportement de Azure Files pour chaque opération FileREST. Ce comportement est basé sur l’état oplock du client SMB qui a déjà acquis un handle sur le même fichier. En outre, le comportement suppose que l’accès et le partage du handle SMB ne sont pas en conflit avec l’opération FileREST.

En cas de conflit, le verrou oplock Descripteur est également rompu pour s'assurer que le descripteur est toujours ouvert sur le client. En cas d’arrêt de blocage, Azure Files devez attendre un accusé de réception indiquant que l’arrêt a réussi. En cas d’arrêt de blocage non bloquant, Azure Files n’a pas besoin d’attendre.

Dans le cas où un blocage oplock break est nécessaire, dans certaines conditions, l’opération FileREST échoue. Si l’arrêt ne réussit pas dans le délai d’expiration de la demande spécifié, ou dans les 30 secondes, selon ce qui se termine en premier, le service retourne status code 408 (Délai d’expiration de la demande) et le code ClientCacheFlushDelayd’erreur .

La Delete File demande nécessite également la rupture du bail de handle d’oplock (H). La rupture du handle garantit qu’aucun handle de fichier n’est toujours ouvert par une application cliente SMB lorsqu’un client REST appelle Delete File. En cas de violation de partage, la demande échoue avec le code status 409 (conflit) et le code SharingViolationd’erreur .

Voir aussi

Azure Files concepts