O que significa "A operação de E / S no endereço do bloco lógico # para o Disco # foi repetida". Quando vista no log de eventos do Windows Server System?

Eu tenho o blade de servidor 2012 configurado para E / S de caminhos múltiplos que mostra avisos como os seguintes durante falha no caminho do MPIO:

A operação de E / S no endereço de bloco lógico 0 para o Disco 7 foi repetida.

Sei o que está causando o aviso, então não estou procurando a causa, mas o que essa mensagem realmente significa?

Isso significa que, se esse pedido de veiculação for uma operação de gravação, o servidor realmente perderá os dados que estava tentando gravar?

Obrigado por qualquer luz que você possa lançar sobre o significado desta mensagem de aviso.

Não, isso não significa que os dados foram perdidos. Isso significa simplesmente que o IRP (IO Request Packet) atingiu o tempo limite enquanto o sistema de E / S aguardava a conclusão e, portanto, foi tentado novamente. Quando um encadeamento inicia qualquer operação de E / S, o gerente de E / S cria um IRP para representar a operação à medida que passa pelo sistema.

O IRP é armazenado em seu estado inicial em uma lista de reserva / reserva, para que possa ser tentado novamente se falhar na primeira vez. Isso fornece a atomicidade que se esperaria de qualquer sistema transacional, para que possamos ter mais certeza de que você não terá um monte de dados corrompidos ou incompletos gravados em seu disco.

Este evento faz todo o sentido no caso de uma falha no MPIO. Digamos que o Windows leia ou grave algo do armazenamento da SAN. A solicitação é enviada e, no mesmo instante, cortei um dos cabos na SAN. Essa solicitação nunca será concluída e, portanto, o Windows tentará a solicitação novamente, mas dessa vez a solicitação seguirá o outro caminho.

Esses eventos também ocorrem quando os discos estão sobrecarregados ou muito lentos. Você pode perceber que essas mensagens coincidem com os backups agendados etc. O disco pode estar lento e ocupado, e o IRP aleatório atingiu o tempo limite e precisou tentar novamente. O IRP pode estar travando em uma rotina de serviço de interrupção, ou em uma chamada de procedimento adiada, ou o que seja.

Pude ver muitos drivers de filtro de E / S na sua pilha exacerbando esse problema também.

Não é que esse comportamento não tenha ocorrido assim nas versões anteriores do Windows, mas a Microsoft aparentemente decidiu apresentar esses eventos no Win8 / Server 2012.

Editar: você pode encontrar os IRPs pendentes de um segmento com um depurador de kernel:, kd> !irp 1a2b3c4donde você encontrou esse endereço anteriormente emitindo o comando kd> !process 8f7d6c4aque listará todos os IRPs associados aos segmentos associados a esse processo. kd> !process 0 0para listar todos os processos em execução.

Depois de listar as informações sobre um IRP usando o comando! Irp, você pode facilmente identificar qual driver manipulou o IRP pela última vez, porque ele terá um >apontador para ele na lista. Em seguida, para obter mais informações sobre o que o driver estava fazendo com o IRP, faça um local kd> !devobj 1a2b3c4d5e6fonde esse é o endereço real do objeto do dispositivo.

Em seguida, kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATAuse o endereço da estrutura PrivateFdoData que você obteve.

Agora você está pronto para despejar a estrutura de dados AllTransferPacketsList obtida de PrivateFdoData.

A idéia é que você esteja rastreando o driver que estava fazendo com o IRP na última vez em que foi visto. Se o IRP for AWOL por muito tempo, o tempo limite será excedido e tentado novamente desde o início. Isso pode ser causado por tantas coisas ... até um raio cósmico perdido. Mas o importante é que a transação será tentada novamente desde o início e não será considerada completa até que o gerente de IO diga que é.

Ah, e também há IO independente de thread, que é uma lata de worms completamente diferente. :)

Para ler mais sobre este tema, eu altamente recomendo o capítulo 8, eu O System /, do Windows Internals 6ª edição, de Mark Russinovich, Margosis, et al.

** Editar: ** Finalmente encontrei o KB oficial para este erro: http://support.microsoft.com/kb/2819485/EN-US

A operação de E / S deve ser repetida 8 vezes, uma vez por minuto, até que o Windows desista.

Edit: Conforme prometido: http://blogs.msdn.com/b/ntdebugging/archive/2013/04/30/interpreting-event-153-errors.aspx

Não, haveria uma mensagem diferente e (espero) uma das camadas do aplicativo lançaria uma exceção se falhassem ao salvar os dados com êxito.

Antes do Windows Server 2012 (ou hotfix 2819485 se no Windows Server 2008 R2), o sistema tentava silenciosamente quando esses tempos limite ocorressem. O objetivo da mensagem é aumentar a visibilidade sobre essas ocorrências. Eles podem indicar um problema de capacidade ou defeito do driver e, no caso do iSCSI, outros defeitos do sistema operacional podem ser atribuídos ao atraso.

No caso de armazenamento externo (sem conexão direta), alguns fornecedores no passado aumentaram o valor do tempo limite, por exemplo, para 60 segundos. No entanto, dado o número padrão de tentativas de componentes de camada superior, como o iniciador iSCSI, isso pode significar que vários minutos podem decorrer antes que o sistema inicie um failover. Obviamente, esse seria um comportamento abaixo do ideal.

Mais Informações:

Entradas do Registro para drivers de miniporta SCSI
http://msdn.microsoft.com/en-us/library/windows/hardware/ff563970%28v=vs.85%29.aspx

https://blogs.msdn.com/b/san/archive/2011/09/01/the-windows-disk-timeout-value-understanding-why-this-should-be-set-to-a-small- value.aspx

A Microsoft lançou uma atualização que fornece a capacidade de especificar o limite para operações storport.sys.

Depois de instalar esta atualização, é possível registrar um evento quando o tempo de latência para o armazenamento de E / S for igual ou superior a um limite. O valor do limite pode ser definido pelo usuário. Esta operação é executada no nível do Driver do Adaptador, para que você possa ver se há um problema de desempenho na SAN. Em seguida, você pode entrar em contato com um fornecedor de armazenamento para resolver o problema.

Nota: Esta atualização restaura a funcionalidade fornecida no Windows 7 e no Windows Server 2008 R2. Quando a funcionalidade está ativada, o valor limite é medido em 100 nanossegundos (0,0001 milissegundos). Além disso, os seguintes valores são registrados no evento:

BuildIoDuration : período de tempo que o MINIPORT passou na função de E / S de compilação para esta solicitação StartIoDuration : período de tempo que o MINIPORT passou na função de E / S inicial para esta solicitação DataTransferLength : tamanho da transferência em bytes

Atualização que aprimora os recursos de log do driver Storport.sys no Windows Server 2012
http://support.microsoft.com/kb/2819476

Atualização cumulativa do Windows 8 e Windows Server 2012: abril de 2013
http://support.microsoft.com/kb/2822241

Pode ser um post tardio, mas descobri que isso pode ser causado com o VSS. Tínhamos um cliente que estava executando o veeam, mas esquecemos de desligar o servidor Windows (o disco foi removido). Isso causou um monte de problemas e esse erro foi o principal.

Parou o backup e wham, sem erros.