Eu tenho multipath IO configurado server 2012 blade que mostra avisos como o seguinte durante a falha do caminho MPIO:
A operação de E/S no endereço de bloco lógico 0 para o Disco 7 foi repetida.
Eu 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 IO foi uma operação de gravação, o servidor realmente perdeu 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. Significa simplesmente que o IRP (IO Request Packet) expirou enquanto o IO System esperava que ele fosse concluído e, portanto, foi tentado novamente. Quando um encadeamento inicia qualquer operação de E/S, o gerenciador de E/S cria um IRP para representar a operação conforme ela passa pelo sistema.
O IRP é armazenado em seu estado inicial em uma lista de buffer/look-aside, para que possa ser repetida se falhar na primeira vez. Isso fornece a atomicidade que se esperaria de qualquer sistema transacional para que possamos estar mais confiantes de que você não obterá um monte de dados corrompidos ou incompletos gravados em seu disco.
Este evento faz todo o sentido no caso de uma falha de MPIO. Digamos que o Windows vá ler ou gravar algo do armazenamento SAN. O pedido é despachado e, no mesmo instante, corto um dos cabos para a SAN. Essa solicitação nunca será concluída e, portanto, o Windows tentará a solicitação novamente, só que desta vez a solicitação seguirá o outro caminho.
Esses eventos também ocorrem quando os discos estão sobrecarregados ou muito lentos. Você pode notar que essas mensagens coincidem com backups agendados, etc. O disco pode estar lento e ocupado, e algum IRP aleatório atingiu o tempo limite e teve que tentar novamente. O IRP pode estar preso em uma rotina de serviço de interrupção, ou uma chamada de procedimento adiada, ou qualquer outra coisa.
Eu pude ver muitos drivers de filtro de E/S em sua pilha exacerbando esse problema também.
Não é que esse comportamento não tenha ocorrido exatamente assim nas versões anteriores do Windows, é apenas que a Microsoft aparentemente decidiu trazer à tona esses eventos no Win8/Server 2012.
Edit: Você pode encontrar os IRPs pendentes de um thread com um depurador de kernel:
kd> !irp 1a2b3c4d, onde você encontrou esse endereço anteriormente emitindo o comandokd> !process 8f7d6c4aque listará todos os IRPs associados aos threads 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 identificar facilmente qual driver lidou com o IRP por último, pois ele terá um
>apontador para ele na lista. Em seguida, para obter mais informações sobre o que esse driver estava fazendo com esse IRP, faça umkd> !devobj 1a2b3c4d5e6fonde esse é o endereço real do objeto de dispositivo.Em seguida, faça um
kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATAusando o endereço da estrutura PrivateFdoData que você obteve.Agora você está pronto para despejar a estrutura de dados AllTransferPacketsList obtida de PrivateFdoData.
A ideia é que você está rastreando qual driver estava fazendo o que com o IRP na última vez em que foi visto. Se o IRP estiver AWOL por muito tempo, ele expirará e será repetido desde o início. Isso pode ser causado por tantas coisas... até mesmo um raio cósmico perdido. Mas o importante é que a transação será repetida desde o início e não será considerada concluída até que o gerente de IO diga que está.
Ah, e também há IO agnóstico de thread, que é uma lata de worms completamente diferente. :)
Para ler mais sobre esse tópico, recomendo o capítulo 8, I/O System, do Windows Internals 6th edition, de Mark Russinovich, Margosis, et al.
** Edit: ** 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.
Editar: Como prometido: https://docs.microsoft.com/en-us/archive/blogs/ntdebugging/interpreting-event-153-errors
Não, haveria uma mensagem diferente e (espero) uma das camadas do aplicativo lançaria uma exceção se não conseguisse salvar os dados com êxito.
Antes do Windows Server 2012 (ou hotfix 2819485 se estiver no Windows Server 2008 R2), o sistema tentaria silenciosamente novamente 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 de driver e, no caso de iSCSI, outros defeitos do sistema operacional podem ser atribuídos ao atraso.
No caso de armazenamento externo (não conectado diretamente), 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 por componentes de camada superior, como o iniciador iSCSI, isso pode significar que vários minutos podem decorrer antes que o sistema inicie um failover. Isso obviamente seria um comportamento abaixo do ideal.
Mais Informações:
Entradas de registro para drivers de miniporta SCSI
http://msdn.microsoft.com/en-us/library/windows/hardware/ff563970%28v=vs.85%29.aspx
https://docs.microsoft.com/en-us/archive/blogs/san/the-windows-disk-timeout-value-less-is-better
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, você pode registrar um evento quando o tempo de latência de E/S para armazenamento for igual ou maior que um limite. O valor limite pode ser definido pelo usuário. Essa 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.
Observação: esta atualização restaura a funcionalidade fornecida no Windows 7 e no Windows Server 2008 R2. Quando a funcionalidade está habilitada, o valor do limite é medido em 100 nanossegundos (0,0001 milissegundos). Além disso, os seguintes valores são registrados no evento:
BuildIoDuration : Tempo que o MINIPORT gastou na função de E/S de compilação para esta solicitação StartIoDuration : Tempo que o MINIPORT gastou na função de E/S inicial para esta solicitação DataTransferLength : Tamanho da transferência em bytes
Atualização que melhora 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 atrasado, mas descobri que isso pode ser causado pelo VSS. Tínhamos um cliente que estava rodando o veeam mas tinha esquecido de desligar o backup do Windows Server (o disco foi removido) Isso causou uma série de problemas e esse erro foi o principal.
Parou o backup e wham, sem erros.