Este enunciado ha sido evaluado por nuestros expertos para garantizar la exactitud de este tutorial.
Solución:
Solución 1:
No, no significa que los datos se hayan perdido. Simplemente significa que se agotó el tiempo de espera del IRP (paquete de solicitud de IO) mientras el sistema IO esperaba que se completara, por lo que se volvió a intentar. Cuando un subproceso comienza cualquier operación de IO, el administrador de IO crea un IRP para representar la operación a medida que pasa por el sistema.
El IRP se almacena en su estado inicial en un búfer/lista de búsqueda, de modo que se puede 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 desde el almacenamiento SAN. Se envía la solicitud y, en el mismo instante, corto uno de los cables a la SAN. Esa solicitud nunca se completará, por lo que Windows intentará la solicitud nuevamente, solo que esta vez la solicitud seguirá la otra ruta.
Estos eventos también ocurren cuando los discos están sobrecargados o son muy lentos. Es posible que observe que estos mensajes coinciden con las copias de seguridad programadas, etc. Es posible que el disco esté lento y ocupado, y que algún IRP aleatorio agotó el tiempo de espera y tuvo que volver a intentarlo. El IRP podría estar atascado en una rutina de servicio de interrupción, o en una llamada de procedimiento diferido, o lo que sea.
Podría 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, es solo que aparentemente Microsoft decidió mostrar estos eventos en Win8/Server 2012.
Editar: Puede encontrar los IRP pendientes de un hilo con un depurador de kernel: kd> !irp 1a2b3c4ddonde anteriormente encontró esa dirección emitiendo el comando kd> !process 8f7d6c4a que enumerará todos los IRP asociados a los subprocesos asociados con ese proceso. kd> !process 0 0 para listar todos los procesos en ejecución.
Una vez que enumere la información sobre un IRP con el comando !irp, podrá detectar fácilmente qué controlador manejó el IRP por última vez porque tendrá un > señalándolo en la lista. Luego, para obtener más información sobre lo que estaba haciendo ese conductor con ese IRP, haga una kd> !devobj 1a2b3c4d5e6f donde esa es la dirección real del objeto del dispositivo.
Entonces haz un kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATA usando la dirección de la estructura PrivateFdoData que obtuviste.
Ahora está listo para volcar la estructura de datos AllTransferPacketsList que obtuvo de PrivateFdoData.
La idea es rastrear qué controlador estaba haciendo qué con el IRP la última vez que se vio. Si el IRP está ausente sin permiso durante demasiado tiempo, se agota el tiempo y se vuelve a intentar desde el principio. Esto puede ser causado por muchas cosas… incluso un rayo cósmico extraviado. Pero lo importante es que la transacción se volverá a intentar desde el principio y no se considerará completa hasta que el administrador de IO lo diga.
Ah, y también hay E/S independiente de subprocesos, que es un completamente diferente lata de gusanos. 🙂
Para leer más sobre este tema, altamente recomendamos el capítulo 8, Sistema de E/S, de Windows Internals 6th edition, de Mark Russinovich, Margosis, et al.
**Editar: ** Finalmente encontré la KB oficial para este error: http://support.microsoft.com/kb/2819485/EN-US
La operación de E/S se debe volver a intentar 8 veces, una vez por minuto, hasta que Windows se dé por vencido.
Editar: según lo prometido: https://docs.microsoft.com/en-us/archive/blogs/ntdebugging/interpreting-event-153-errors
Solución 2:
No, habría un mensaje diferente y (con suerte) una de las capas de la aplicación lanzaría una excepción si no pudiera guardar los datos correctamente.
Antes de Windows Server 2012 (o la revisión 2819485 si estaba en Windows Server 2008 R2), el sistema reintentaba en silencio cuando ocurrían estos tiempos de espera. El propósito del mensaje es aumentar la visibilidad sobre estos sucesos. Pueden indicar un problema de capacidad o un defecto del controlador y, en el caso de iSCSI, otros defectos del sistema operativo pueden attribute al retraso.
En el caso del almacenamiento externo (no adjunto directo), algunos proveedores en el pasado aumentaron el valor del tiempo de espera, por ejemplo, a 60 segundos. Sin embargo, dada la cantidad predeterminada de reintentos de los componentes de capa superior, como el iniciador iSCSI, esto podría significar que pueden transcurrir varios minutos antes de que el sistema inicie una conmutación por error. Eso obviamente sería un comportamiento subóptimo.
Más información:
Entradas de registro para controladores de minipuerto 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
Microsoft ha publicado una actualización que brinda la capacidad de especificar el umbral para las operaciones de storport.sys.
Después de instalar esta actualización, puede registrar un evento cuando el tiempo de latencia de E/S en el almacenamiento sea igual o superior a un umbral. El valor umbral puede ser establecido por el usuario. Esta operación se realiza en el nivel del controlador del adaptador para que pueda ver si hay un problema de rendimiento en la SAN. Luego, puede ponerse en contacto con un proveedor de almacenamiento para solucionar el problema.
Nota: Esta actualización restaura la funcionalidad que se proporcionó en Windows 7 y Windows Server 2008 R2. Cuando la funcionalidad está habilitada, el valor del umbral se mide en 100 nanosegundos (0,0001 milisegundos). Además, los siguientes valores se registran en el evento:
BuildIoDuration: Lapso de tiempo que el MINIPORT ha pasado en la función de E/S de compilación para esta solicitud
StartIoDuration: Tiempo que el MINIPORT ha estado en la función de inicio de E/S para esta solicitud
Longitud de transferencia de datos: Tamaño de la transferencia en bytes
Actualización que mejora las capacidades de registro del controlador Storport.sys en Windows Server 2012
http://support.microsoft.com/kb/2819476
Actualización acumulativa de Windows 8 y Windows Server 2012: abril de 2013
http://support.microsoft.com/kb/2822241
Solución 3:
Puede ser una publicación tardía, pero descubrí que puede deberse a VSS. Teníamos un cliente que estaba ejecutando Veeam pero se olvidó de desactivar la copia de seguridad del servidor de Windows (se eliminó el disco). Causó una gran cantidad de problemas y este error fue el principal.
Detuve la copia de seguridad y wham, sin errores.
Acuérdate de que tienes la opción de reseñar si te ayudó.