Blocages cassants
Une fois qu’un oplock est demandé et accordé, le propriétaire de ce verrou d’opération a accès au flux en fonction du type d’oplock demandé. Si l’opération reçue n’est pas compatible avec le verrou d’opération actuel, le système l’interrompt.
Lorsqu’un oplock est accordé, le système met en pendant le IRP de demande. Lorsqu’un oplock est rompu, l’IRP de requête de l’oplock suspendu est terminé avec STATUS_SUCCESS. Pour les oplocks de niveau 1, Batch et Filter, le membre IoStatus.Information de l’IRP est défini pour indiquer le niveau auquel le verrouillage d’opération se brise. Ces niveaux sont les suivants :
FILE_OPLOCK_BROKEN_TO_NONE : le verrouillage d’opération a été rompu et il n’y a pas de verrouillage d’opération actuel sur le flux. On dit que l’oplock a été « rompu à Aucun ».
FILE_OPLOCK_BROKEN_TO_LEVEL_2 : le verrou d’opération actuel (niveau 1 ou lot) a été converti en un verrou d’opération de niveau 2. Les oplocks de filtre ne s’arrêtent jamais au niveau 2, ils s’arrêtent toujours à Aucun.
Pour les verrous oplocks Read-Handle, Read-Write et Read-Write-Handle, le niveau auquel le verrou oplock se brise est décrit comme une combinaison de zéro ou plus des indicateurs OPLOCK_LEVEL_CACHE_READ, OPLOCK_LEVEL_CACHE_HANDLE ou OPLOCK_LEVEL_CACHE_WRITE dans le membre NewOplockLevel de la structure REQUEST_OPLOCK_OUTPUT_BUFFER passée en tant que paramètre lpOutBuffer de DeviceIoControl. De la même manière, FltFsControlFile et ZwFsControlFile peuvent être utilisés pour demander des oplocks Windows 7 à partir du mode noyau. Pour plus d’informations, consultez FSCTL_REQUEST_OPLOCK.
Lorsque le package oplock du système interrompt un niveau 1, Batch, Filter, Read-Write, Read-Write-Handle ou, dans certaines circonstances, un Read-Handle oplock :
- Le package oplock termine l’IRP de demande oplock suspendu.
- L’opération qui a provoqué l’arrêt de l’oplock est elle-même suspendu.
Si l’opération est émise sur un handle synchrone ou s’il s’agit d’un IRP_MJ_CREATE, qui est toujours synchrone, le gestionnaire d’E/S provoque le blocage de l’opération, au lieu de retourner STATUS_PENDING, en attendant qu’un accusé de réception du propriétaire du verrou d’opération indique au package oplock qu’il a terminé son traitement et qu’il est sûr que l’opération interrompue se poursuive. L’objectif de ce délai est de permettre au propriétaire de l’oplock de remettre le flux dans un état cohérent avant que l’opération actuelle ne se poursuive. Le système attend toujours de recevoir l’accusé de réception, car il n’y a pas de délai d’expiration. Il incombe donc au propriétaire de l’oplock d’accuser réception de la rupture en temps opportun. L’IRP de l’opération suspendu est définie dans un état annulable. Si l’application ou le pilote qui effectue l’attente se termine, le package oplock termine immédiatement l’IRP avec STATUS_CANCELLED.
Un IRP IRP_MJ_CREATE peut spécifier l’option FILE_COMPLETE_IF_OPLOCKED créer pour éviter d’être bloqué dans le cadre de l’accusé de réception d’arrêt du verrouillage. Cette option indique au package oplock de ne pas bloquer l’IRP de création jusqu’à ce que l’accusé de réception de l’arrêt d’opération soit reçu. Au lieu de cela, la création est autorisée à continuer. Si une création réussie entraîne un blocage d’opération, le code de retour est STATUS_OPLOCK_BREAK_IN_PROGRESS, plutôt que STATUS_SUCCESS. L’indicateur FILE_COMPLETE_IF_OPLOCKED est généralement utilisé pour éviter les interblocages. Par exemple, si un client est propriétaire d’un oplock sur un flux et que le même client ouvre ultérieurement le même flux, le client bloque l’attente d’un accusé de réception de l’arrêt du blocage. Dans ce scénario, l’utilisation de l’indicateur FILE_COMPLETE_IF_OPLOCKED évite l’interblocage.
Étant donné que le système de fichiers NTFS lance des sauts d’opération pour les verrous d’opération Batch et Filter avant de vérifier les violations de partage, il est possible qu’une création qui FILE_COMPLETE_IF_OPLOCKED spécifiée échoue avec STATUS_SHARING_VIOLATION tout en entraînant l’arrêt d’un oplock Batch ou Filter. Dans ce cas, le membre d’informations de la structure IO_STATUS_BLOCK est défini sur FILE_OPBATCH_BREAK_UNDERWAY pour permettre à l’appelant de détecter ce cas.
Pour les oplocks Read-Handle et read-write-handle, l’arrêt de verrouillage d’opération est lancé après que NTFS a vérifié et détecté une violation de partage. Cela donne aux détenteurs de ces oplocks la possibilité de fermer leurs handles et de se déconnecter, ce qui permet de ne pas renvoyer la violation de partage à l’utilisateur. Il évite également de briser inconditionnellement le verrou d’opération dans les cas où le handle que le cache oplock n’entre pas en conflit avec la nouvelle création.
Lorsque le niveau 2, la lecture et, dans certaines circonstances, Read-Handle verrous d’opération s’arrêtent, le système n’attend pas d’accusé de réception. Cela est dû au fait qu’aucun état mis en cache sur le flux ne doit être restauré dans le fichier avant d’autoriser d’autres clients à y accéder.
Certaines opérations de système de fichiers case activée l’état actuel du verrouillage d’opération pour déterminer si le verrouillage d’opération doit être rompu. Les articles suivants répertorient chaque opération et décrivent ce qui déclenche un arrêt d’opération, ce qui détermine le niveau auquel le blocage d’opération se brise et si un accusé de réception de l’arrêt est nécessaire :
L’arrêt d’un oplock Windows 7 nécessite un accusé de réception si l’indicateur REQUEST_OPLOCK_OUTPUT_FLAG_ACK_REQUIRED est défini dans le membre Indicateurs de la structure REQUEST_OPLOCK_OUTPUT_BUFFER passé en tant que paramètre de sortie de DeviceIoControl(lpOutBuffer), FltFsControlFile(OutBuffer) ou ZwFsControlFile(OutBuffer). Pour plus d’informations, consultez FSCTL_REQUEST_OPLOCK.
Les articles par opération répertoriés décrivent les détails de l’arrêt d’un Read-Handle oplock entraîne l’attente de l’opération qui l’a brisé. Par exemple, l’article IRP_MJ_CREATE contient les détails Read-Handle associés.