Che cosa significa "È stata ritentata l'operazione IO sull'indirizzo di blocco logico n. Per # disco." Quando viene visualizzato nel registro eventi del sistema Windows Server?


22

Ho un server blade 2012 configurato multipath IO che mostra avvisi come i seguenti durante l'errore del percorso MPIO:

È stata ritentata l'operazione IO sull'indirizzo di blocco logico 0 per il disco 7.

So cosa sta causando l'avvertimento, quindi non sto cercando la causa, ma cosa significa effettivamente questo messaggio?

Significa che se questo IO era un'operazione di scrittura, il server ha effettivamente perso i dati che stava cercando di scrivere?

Grazie per qualsiasi luce tu possa gettare sul significato di questo messaggio di avviso.

Risposte:


28

No, ciò non significa che i dati siano stati persi. Significa semplicemente che l'IRP (IO Request Packet) è scaduto mentre l'IO System aspettava che si completasse, quindi è stato riprovato. Quando un thread inizia qualsiasi operazione IO, l'IO Manager crea un IRP per rappresentare l'operazione mentre passa attraverso il sistema.

L'IRP viene archiviato nel suo stato iniziale in un elenco buffer / di ricerca, in modo che possa essere riprovato se fallisce la prima volta. Ciò fornisce l'atomicità che ci si aspetterebbe da qualsiasi sistema transazionale in modo da poter essere più sicuri che non si otterrà un mucchio di dati corrotti o incompleti scritti sul disco.

Questo evento ha perfettamente senso in caso di errore MPIO. Supponiamo che Windows vada a leggere o scrivere qualcosa dalla memoria SAN. La richiesta viene inviata e nello stesso istante taglio uno dei cavi alla SAN. La richiesta non verrà mai completata e quindi Windows tenterà nuovamente la richiesta, solo che questa volta seguirà l'altro percorso.

Questi eventi si verificano anche quando i dischi sono sovraccarichi o semplicemente molto lenti. Potresti notare che questi messaggi coincidono con i backup pianificati, ecc. Il disco potrebbe essere lento e occupato e alcuni IRP casuali sono scaduti e hanno dovuto riprovare. L'IRP potrebbe rimanere bloccato in una routine di servizio di interruzione, in una chiamata di procedura differita o altro.

Potrei vedere un sacco di driver filtro IO nel tuo stack esacerbare anche questo problema.

Non è che questo comportamento non si sia verificato in questo modo nelle versioni precedenti di Windows, è solo che Microsoft ha deciso di presentare questi eventi in Win8 / Server 2012.

Modifica: puoi trovare gli IRP in sospeso di un thread con un debugger del kernel:, kd> !irp 1a2b3c4ddove hai precedentemente trovato quell'indirizzo emettendo il comando kd> !process 8f7d6c4ache elencherà tutti gli IRP associati ai thread associati a quel processo. kd> !process 0 0per elencare tutti i processi in esecuzione.

Dopo aver elencato le informazioni su un IRP usando il comando! Irp, puoi facilmente individuare quale driver ha gestito l'IRP per ultimo perché avrà un >puntamento ad esso nell'elenco. Quindi, per ottenere maggiori informazioni su ciò che quel driver stava facendo con quell'IRP, fai un indirizzo kd> !devobj 1a2b3c4d5e6fdove si trova l'oggetto reale del dispositivo.

Quindi fai un kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATAusando l'indirizzo della struttura PrivateFdoData che hai.

Ora sei pronto per scaricare la struttura di dati AllTransferPacketsList ottenuta da PrivateFdoData.

L'idea è che stai rintracciando quale driver stava facendo cosa con l'IRP l'ultima volta che è stato visto. Se l'IRP è AWOL per troppo tempo, è scaduto e riprovato dall'inizio. Ciò può essere causato da così tante cose ... persino un raggio cosmico vagante. Ma la cosa importante è che la transazione verrà ritentata dall'inizio e non sarà considerata completa fino a quando il gestore IO non lo dirà.

Oh, e c'è anche IO indipendente dal thread che è una lattina di worm completamente diversa. :)

Per ulteriori approfondimenti su questo argomento, consiglio vivamente il capitolo 8, Sistema I / O, della sesta edizione di Windows Internals, di Mark Russinovich, Margosis, et al.

** Modifica: ** Ho finalmente trovato il KB ufficiale per questo errore: http://support.microsoft.com/kb/2819485/EN-US

L'operazione IO deve essere ripetuta 8 volte, una volta al minuto, fino a quando Windows non si arrende.

Modifica: come promesso: http://blogs.msdn.com/b/ntdebugging/archive/2013/04/30/interpreting-event-153-errors.aspx


1
Grazie Ryan, speravo che significasse che la richiesta è stata ritirata ma i dati non sono stati persi e un'altra richiesta sarebbe stata creata per provare a scrivere nuovamente i dati. Puoi fare riferimento a una delle fonti per la tua risposta (libri, articoli, una nota che indica che hai accesso al codice sorgente di Windows perché sei un grande cliente EA e hai fatto una traccia di debug per trovare queste informazioni, ecc.)? Mi piacerebbe comprenderlo ulteriormente.
Chris Magnuson,

2
Ho modificato il mio post per rispondere alle tue domande di follow-up. È probabile che avrò più informazioni da aggiungere in seguito.
Ryan Ries,

2
Chiunque possa passare al debugger di Windows per supportare il proprio punto guadagna alcuni complimenti nel mio libro. Non è stato possibile votare nuovamente la risposta, quindi sarà necessario aggiungere il commento. Ho Windows Internals 6th edition part 1 e ora sto per acquistare la parte 2 con il capitolo 8. Grazie
Chris Magnuson,


6

No, ci sarebbe un messaggio diverso e (si spera) uno dei livelli dell'applicazione genererebbe un'eccezione se non riuscisse a salvare correttamente i dati.

Prima di Windows Server 2012 (o aggiornamento rapido 2819485 se su Windows Server 2008 R2), il sistema avrebbe riprovato in silenzio quando si sono verificati questi timeout. Lo scopo del messaggio è aumentare la visibilità di queste occorrenze. Possono indicare un problema di capacità o un difetto del driver e, nel caso di iSCSI, altri difetti del sistema operativo possono attribuire al ritardo.

Nel caso di archiviazione esterna (non collegata direttamente), in passato alcuni fornitori hanno aumentato il valore di timeout, ad esempio a 60 secondi. Tuttavia, dato il numero predefinito di tentativi da parte di componenti di livello superiore come l'iniziatore iSCSI, ciò potrebbe significare che potrebbero trascorrere diversi minuti prima che il sistema avvii un failover. Questo sarebbe ovviamente un comportamento non ottimale.

Maggiori informazioni:

Voci di registro per driver SCSI Miniport
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


Microsoft ha rilasciato un aggiornamento che offre la possibilità di specificare la soglia per le operazioni storport.sys.

Dopo aver installato questo aggiornamento, è possibile registrare un evento quando il tempo di latenza per l'I / O nella memoria è uguale o maggiore di una soglia. Il valore di soglia può essere impostato dall'utente. Questa operazione viene eseguita a livello del driver dell'adattatore in modo da poter vedere se c'è un problema di prestazioni sulla SAN. Quindi, è possibile contattare un fornitore di archiviazione per risolvere il problema.

Nota: questo aggiornamento ripristina le funzionalità fornite in Windows 7 e Windows Server 2008 R2. Quando la funzionalità è abilitata, il valore di soglia viene misurato in 100 nanosecondi (0,0001 millisecondi). Inoltre, nell'evento vengono registrati i seguenti valori:

BuildIoDuration : periodo di tempo trascorso da MINIPORT nella funzione I / O build per questa richiesta StartIoDuration : periodo di tempo trascorso da MINIPORT nella funzione I / O start per questa richiesta DataTransferLength : dimensione del trasferimento in byte

Aggiornamento che migliora le capacità di registrazione del driver Storport.sys in Windows Server 2012
http://support.microsoft.com/kb/2819476

Aggiornamento cumulativo di Windows 8 e Windows Server 2012: aprile 2013
http://support.microsoft.com/kb/2822241


4

Potrebbe essere un post in ritardo, ma ho scoperto che può essere causato con VSS. Avevamo un client che stava eseguendo Veeam ma che avevamo dimenticato di disattivare il backup di Windows Server (il disco era stato rimosso). Ciò causava un carico di problemi e questo era il principale.

Fermato il backup e wham, nessun errore.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.