No, no significa que los datos se hayan perdido. Simplemente significa que el IRP (IO Request Packet) se agotó mientras el Sistema IO esperaba a que se completara, y entonces se intentó de nuevo. Cuando un hilo comienza cualquier operación de IO, el gestor de IO crea un IRP para representar la operación mientras pasa por el sistema.
El IRP se almacena en su estado inicial en una lista buffer/look-aside, para que pueda ser reintentado si falla la primera vez. Esto proporciona la atomicidad que uno esperaría de cualquier sistema transaccional, de modo que podemos estar más seguros de que no vas a tener un montón de datos corruptos o incompletos escritos en tu disco.
Este evento tiene mucho sentido en el caso de un fallo de MPIO. Digamos que Windows va a leer o escribir algo del almacenamiento SAN. La petición se despacha, y en el mismo instante, corto uno de los cables a la SAN. Esa petición nunca se va a completar, y entonces Windows intentará la petición de nuevo, sólo que esta vez la petición seguirá el otro camino.
Estos eventos también ocurren cuando los discos están sobrecargados o simplemente son muy lentos. Puedes notar que estos mensajes coinciden con copias de seguridad programadas, etc. El disco puede estar lento y ocupado, y algún IRP aleatorio se ha agotado y ha tenido que intentarlo de nuevo. El IRP podría estar atascado en una rutina de servicio de interrupción, o una llamada de procedimiento diferida, o lo que sea.
Podría ver que tener un montón de controladores de filtro IO en su pila exacerba este problema también.
No es que este comportamiento no ocurriera igual en versiones anteriores de Windows, es que aparentemente Microsoft decidió sacar a la luz estos eventos en Win8/Server 2012.
Editar: Puedes encontrar los IRPs pendientes de un hilo con un depurador del kernel: kd> !irp 1a2b3c4d , donde previamente encontró esa dirección emitiendo el comando kd> !process 8f7d6c4a que listará todos los IRP asociados a los hilos asociados a ese proceso. kd> !process 0 0 para listar todos los procesos en ejecución.
Una vez que se liste la información sobre un IRP usando el comando !irp, se puede detectar fácilmente cuál fue el último controlador que manejó el IRP porque tendrá un > señalándolo en la lista. Luego, para obtener más información sobre lo que ese controlador estaba haciendo con ese IRP, haz un kd> !devobj 1a2b3c4d5e6f donde es la dirección real del objeto dispositivo.
Entonces haz un kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATA utilizando la dirección de la estructura PrivateFdoData que obtuvo.
Ahora está listo para volcar la estructura de datos AllTransferPacketsList que obtuvo de PrivateFdoData.
La idea es que se está rastreando qué conductor estaba haciendo qué con el IRP la última vez que se vio. Si el IRP está ausente por mucho tiempo, se le da un tiempo de espera y se vuelve a intentar desde el principio. Esto puede ser causado por muchas cosas... incluso un rayo cósmico perdido. Pero lo importante es que la transacción será reintentada desde el principio, y no se considerará completa hasta que el gestor de IO diga que lo está.
Ah, y también hay IO agnóstica de hilos que es una completamente otra lata de gusanos. :)
Para más información sobre este tema, yo altamente recomiendan el capítulo 8, I/O System, de Windows Internals 6th edition, de Mark Russinovich, Margosis, et al.
**Edición: ** Finalmente encontré la KB oficial para este error: http://support.microsoft.com/kb/2819485/EN-US
La operación de IO debe reintentarse 8 veces, una por minuto, hasta que Windows se rinda.
Edición: Como se prometió: https://docs.microsoft.com/en-us/archive/blogs/ntdebugging/interpreting-event-153-errors
