¿Qué significa "La operación de E / S en la dirección del bloque lógico # para el disco # reintentado" significa cuando se ve en el registro de eventos del sistema del servidor de Windows?

Tengo el servidor 2012 de varias rutas configurado como IO que muestra advertencias como las siguientes durante la falla de la ruta MPIO:

Se reintentó la operación IO en la dirección de bloque lógico 0 para el Disco 7.

Sé lo que está causando la advertencia, así que no estoy buscando la causa, pero ¿qué significa realmente este mensaje?

¿Significa que si este IO fue una operación de escritura, el servidor realmente perdió los datos que estaba tratando de escribir?

Gracias por cualquier luz que pueda arrojar sobre el significado de este mensaje de advertencia.

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

No, habría un mensaje diferente, y (con suerte) una de las capas de la aplicación arrojaría una excepción si no pudiera guardar los datos con éxito.

Antes de Windows Server 2012 (o la revisión 2819485 si está en Windows Server 2008 R2), el sistema volvería a intentar en silencio cuando se produjeran 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 atribuirse a la demora.

En el caso del almacenamiento externo (no conectado directamente), algunos proveedores en el pasado han aumentado el valor del tiempo de espera, por ejemplo, a 60 segundos. Sin embargo, dado el número predeterminado de reintentos por parte de 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 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 lanzó 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 para el almacenamiento de E / S es igual o mayor que 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 comunicarse con un proveedor de almacenamiento para abordar 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 umbral se mide en 100 nanosegundos (0,0001 milisegundos). Además, los siguientes valores se registran en el evento:

BuildIoDuration : Tiempo que MINIPORT ha pasado en la función de E / S de compilación para esta solicitud StartIoDuration : Tiempo que MINIPORT ha pasado en la función de E / S de inicio para esta solicitud DataTransferLength : 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

Podría ser una publicación tardía, pero he descubierto que puede ser causada con VSS. Teníamos un cliente que ejecutaba veeam pero se había olvidado de apagar el servidor de Windows (se retiró el disco) Causó una gran cantidad de problemas y este error fue el principal.

Detuve la copia de seguridad y wham, sin errores.