No, no significa que se hayan perdido los datos. Simplemente significa que el IRP (paquete de solicitud de IO) agotó el tiempo de espera mientras el sistema IO esperaba a que se completara, por lo que se intentó nuevamente. Cuando un subproceso comienza cualquier operación de E / S, el administrador de E / S crea un IRP para representar la operación a medida que pasa por el sistema.
El IRP se almacena en su estado inicial en una lista de buffer / look -side, para que se pueda volver a intentar si falla la primera vez. Eso proporciona la atomicidad que uno esperaría de cualquier sistema transaccional para que podamos estar más seguros de que no obtendrá un montón de datos corruptos o incompletos escritos en su disco.
Este evento tiene mucho sentido en el caso de una falla de MPIO. Digamos que Windows va a leer o escribir algo del almacenamiento SAN. Se envía la solicitud y, en el mismo instante, corté uno de los cables a la SAN. Esa solicitud nunca se completará, por lo que Windows volverá a intentar la solicitud, solo que esta vez la solicitud seguirá la otra ruta.
Estos eventos también ocurren cuando los discos están sobrecargados o simplemente muy lentos. Es posible que observe que estos mensajes coinciden con las copias de seguridad programadas, etc. El disco puede estar lento y ocupado, y algunos IRP aleatorios se agotaron y tuvieron que intentarlo nuevamente. El IRP podría estar atascado en una rutina de servicio de interrupción, o una llamada de procedimiento diferido, o lo que sea.
Pude ver que tener muchos controladores de filtro IO en su pila también exacerba este problema.
No es que este comportamiento no ocurriera así en versiones anteriores de Windows, sino que Microsoft aparentemente decidió sacar a la superficie estos eventos en Win8 / Server 2012.
Editar: puede encontrar los IRP pendientes de un subproceso con un depurador de kernel: kd> !irp 1a2b3c4ddonde anteriormente encontró esa dirección emitiendo el comando kd> !process 8f7d6c4aque enumerará todos los IRP asociados a los subprocesos asociados con ese proceso. kd> !process 0 0para enumerar todos los procesos en ejecución.
Una vez que enumere la información sobre un IRP utilizando el comando! Irp, puede detectar fácilmente qué controlador manejó el IRP por última vez porque tendrá un >apunte en la lista. Luego, para obtener más información sobre lo que estaba haciendo ese controlador con ese IRP, haga un lugar kd> !devobj 1a2b3c4d5e6fdonde esa sea la dirección real del objeto del dispositivo.
Luego, kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATAutilice 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 estás rastreando qué controlador estaba haciendo qué con el IRP la última vez que se vio. Si el IRP es AWOL durante demasiado tiempo, se agota el tiempo y se vuelve a intentar desde el principio. Esto puede ser causado por tantas cosas ... incluso un rayo cósmico perdido. Pero lo importante es que la transacción se volverá a intentar desde el principio y no se considerará completa hasta que el gerente de E / S diga que sí.
Ah, y también hay IO sin hilos que es una lata de gusanos completamente diferente. :)
Para leer más sobre este tema, me altamente recomiendo el capítulo 8, Sistema de E / S, de Windows Internals 6ª edición, de Mark Russinovich, Margosis, et al.
** Editar: ** Finalmente encontré el KB oficial para este error: http://support.microsoft.com/kb/2819485/EN-US
La operación IO debe reintentarse 8 veces, una vez por minuto, hasta que Windows se rinda.
Editar: según lo prometido: http://blogs.msdn.com/b/ntdebugging/archive/2013/04/30/interpreting-event-153-errors.aspx