Partilhar via

Quebrando Oplocks

Depois de um oplock ser solicitado e concedido, o proprietário desse oplock tem acesso ao fluxo com base no tipo de oplock que foi solicitado. Se a operação recebida não for compatível com o oplock atual, o sistema rompe o oplock.

Quando um oplock é concedido, o sistema suspende o IRP solicitante. Quando um oplock é quebrado, a IRP da solicitação pendente do oplock é concluída com STATUS_SUCCESS. Para os oplocks de Nível 1, Em Lote e Filtro, o membro IoStatus.Information do IRP é definido para indicar o nível para o qual o oplock se está a quebrar. Estes níveis são:

  • FILE_OPLOCK_BROKEN_TO_NONE: O oplock foi quebrado e não há nenhum oplock atual no fluxo de dados. Diz-se que o oplock está "quebrado para Nenhum".

  • FILE_OPLOCK_BROKEN_TO_LEVEL_2: O oplock atual (Nível 1 ou Batch) foi convertido para um oplock de Nível 2. Os oplocks de filtro nunca quebram para o Nível 2, eles sempre quebram para Nenhum.

Para os oplocks Read-Handle, Read-Write e Read-Write-Handle, o nível para o qual a quebra do oplock está a ocorrer é descrito como uma combinação de zero ou mais dos sinalizadores OPLOCK_LEVEL_CACHE_READ, OPLOCK_LEVEL_CACHE_HANDLE ou OPLOCK_LEVEL_CACHE_WRITE no membro NewOplockLevel da estrutura REQUEST_OPLOCK_OUTPUT_BUFFER passado como o parâmetro lpOutBuffer de DeviceIoControl. De maneira semelhante, FltFsControlFile e ZwFsControlFile podem ser usados para solicitar oplocks no modo kernel do Windows 7. Para obter mais informações, consulte FSCTL_REQUEST_OPLOCK.

Quando o pacote oplock do sistema quebra um oplock de Nível 1, Batch, Filter, Read-Write, Read-Write-Handle ou, em determinadas circunstâncias, um oplock de Read-Handle:

  • O pacote de controlo de bloqueio completo o IRP da solicitação de bloqueio suspensa.
  • A operação que causou a quebra do oplock está pendente.

O gestor de E/S causa o bloqueio da operação, em vez de retornar STATUS_PENDING, se a operação:

  • É emitido em uma alça síncrona.
  • É um IRP_MJ_CREATE, que é sempre síncrono.

O gestor de E/S aguarda um reconhecimento do proprietário do oplock para informar ao pacote de oplock que o processamento foi concluído e é seguro para a operação pendente prosseguir. Este atraso permite que o proprietário do oplock restaure o fluxo a um estado consistente antes que a operação atual prossiga. O sistema esperaria para sempre para receber o reconhecimento, pois não há tempo limite. Cabe, portanto, ao dono do oplock reconhecer a quebra em tempo hábil. O IRP da operação suspensa é definido em um estado cancelável. Se o aplicativo ou driver que executa a espera terminar, o pacote oplock concluirá imediatamente o IRP com STATUS_CANCELLED.

Um IRP_MJ_CREATE IRP pode especificar a opção de criação FILE_COMPLETE_IF_OPLOCKED para evitar ser bloqueado como parte do reconhecimento da quebra de bloqueio. Esta opção diz ao pacote oplock para não bloquear o IRP de criação até que a confirmação de quebra de oplock seja recebida. Em vez disso, a criação pode continuar. Se uma criação bem-sucedida resultar numa quebra de oplock, o código de retorno será STATUS_OPLOCK_BREAK_IN_PROGRESS, em vez de STATUS_SUCCESS. O sinalizador FILE_COMPLETE_IF_OPLOCKED é normalmente usado para evitar impasses. Por exemplo, se um cliente possui um oplock em um fluxo e o mesmo cliente posteriormente abre o mesmo fluxo, o cliente bloquearia a espera por si mesmo para reconhecer a quebra de oplock. Nesse cenário, o uso do sinalizador FILE_COMPLETE_IF_OPLOCKED evita o deadlock.

O sistema de arquivos NTFS inicia a interrupção de oplocks para oplocks de Batch e de Filtro antes de verificar violações de compartilhamento. Portanto, é possível que uma criação que especificou FILE_COMPLETE_IF_OPLOCKED falhe com STATUS_SHARING_VIOLATION, mas ainda provoque a quebra de um bloqueio Batch ou de filtro. Nesse caso, o membro de informação da estrutura IO_STATUS_BLOCK é definido como FILE_OPBATCH_BREAK_UNDERWAY para que o chamador possa detetar este caso.

Para os bloqueios de leitura Read-Handle e Read-Write-Handle, a quebra de oplock é iniciada depois que o NTFS verifica e deteta uma violação de partilha. Esta sequência dá aos detentores de oplock a oportunidade de fechar suas alças e sair do caminho, permitindo assim a possibilidade de não retornar a violação de compartilhamento para o usuário. Ele também evita quebrar incondicionalmente o oplock nos casos em que o identificador que o oplock armazena em cache não entra em conflito com a nova criação.

Quando o Nível 2, Ler e, em certas circunstâncias, Read-Handle oplocks quebram, o sistema não espera por uma confirmação. O motivo é que não deve haver nenhum estado armazenado em cache no fluxo que precise ser restaurado para o arquivo antes de permitir que outros clientes acessem ele.

Há certas operações do sistema de arquivos que verificam o estado atual do oplock para determinar se o oplock precisa ser interrompido. Os seguintes artigos específicos da operação descrevem o que aciona uma quebra de oplock, o que determina o nível para o qual o oplock quebra e se uma confirmação da quebra é necessária:

Uma quebra de um oplock do Windows 7 requer uma confirmação se o sinalizador REQUEST_OPLOCK_OUTPUT_FLAG_ACK_REQUIRED estiver definido no Flags membro da estrutura REQUEST_OPLOCK_OUTPUT_BUFFER, passado como parâmetro de saída em DeviceIoControl(lpOutBuffer), FltFsControlFile(OutBuffer) ou ZwFsControlFile(OutBuffer). Para obter mais informações, consulte FSCTL_REQUEST_OPLOCK.

Os artigos listados por operação descrevem os detalhes de quando uma quebra de um Read-Handle oplock resulta na suspensão da operação que o interrompeu. Por exemplo, o artigo IRP_MJ_CREATE contém os detalhes associados do Read-Handle.

  • Last updated on