Que signifie «L'opération d'E / S à l'adresse de bloc logique # pour le disque # a été réessayée». Lorsqu'elle apparaît dans le journal des événements du système Windows Server?

J'ai une lame de serveur 2012 configurée par E / S multichemin qui affiche des avertissements comme ceux-ci lors de l'échec du chemin MPIO:

L'opération d'E / S à l'adresse de bloc logique 0 pour le disque 7 a été réessayée.

Je sais ce qui provoque l'avertissement, donc je ne recherche pas la cause, mais que signifie réellement ce message?

Cela signifie-t-il que si cet E / S était une opération d'écriture, le serveur a en fait perdu des données qu'il essayait d'écrire?

Merci pour toute lumière que vous pouvez apporter sur la signification de ce message d'avertissement.

Non, cela ne signifie pas que les données ont été perdues. Cela signifie simplement que l'IRP (IO Request Packet) a expiré pendant que le système IO attendait qu'il se termine, et il a donc été réessayé. Lorsqu'un thread commence une opération d'E / S, le gestionnaire d'E / S crée un IRP pour représenter l'opération lors de son passage dans le système.

L'IRP est stocké dans son état initial dans une liste tampon / liste d'attente, de sorte qu'il peut être réessayé s'il échoue la première fois. Cela fournit l'atomicité que l'on peut attendre de n'importe quel système transactionnel afin que nous puissions être plus sûrs que vous n'obtiendrez pas un tas de données corrompues ou incomplètes écrites sur votre disque.

Cet événement prend tout son sens en cas de défaillance de MPIO. Dites que Windows va lire ou écrire quelque chose à partir du stockage SAN. La demande est envoyée, et au même instant, j'ai coupé l'un des câbles au SAN. Cette demande ne se terminera jamais, et donc Windows réessaiera la demande, mais cette fois, la demande suivra l'autre chemin.

Ces événements se produisent également lorsque les disques sont surchargés ou tout simplement très lents. Vous pouvez remarquer que ces messages coïncident avec des sauvegardes planifiées, etc. Le disque peut simplement être lent et occupé, et certains IRP aléatoires ont expiré et ont dû réessayer. L'IRP peut être bloqué dans une routine de service d'interruption, ou un appel de procédure différée, ou autre.

Je pouvais voir que beaucoup de pilotes de filtre d'E / S dans votre pile exacerbaient également ce problème.

Ce n'est pas que ce comportement ne s'est pas produit comme cela dans les versions précédentes de Windows, c'est juste que Microsoft a apparemment décidé de faire apparaître ces événements dans Win8 / Server 2012.

Edit: Vous pouvez trouver les IRP en suspens d'un thread avec un débogueur de noyau:, kd> !irp 1a2b3c4doù vous avez précédemment trouvé cette adresse en émettant la commande kd> !process 8f7d6c4aqui listera tous les IRP associés aux threads associés à ce processus. kd> !process 0 0pour répertorier tous les processus en cours d'exécution.

Une fois que vous avez répertorié les informations sur un IRP à l'aide de la commande! Irp, vous pouvez facilement repérer le pilote qui a géré l'IRP pour la dernière fois car il y aura un >pointage dans la liste. Ensuite, pour obtenir plus d'informations sur ce que ce pilote faisait avec cet IRP, faites une kd> !devobj 1a2b3c4d5e6foù c'est l'adresse réelle de l'objet périphérique.

kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATAEffectuez ensuite une utilisation de l'adresse de la structure PrivateFdoData que vous avez obtenue.

Vous êtes maintenant prêt à vider la structure de données AllTransferPacketsList que vous avez obtenue de PrivateFdoData.

L'idée est que vous traquez quel pilote faisait quoi avec l'IRP la dernière fois qu'il a été vu. Si l'IRP est AWOL depuis trop longtemps, il est expiré et réessayé depuis le début. Cela peut être causé par tant de choses ... même un rayon cosmique errant. Mais l'important est que la transaction sera réessayée depuis le début et qu'elle ne sera considérée comme terminée que lorsque le responsable des E / S le dira.

Oh, et il y a aussi des entrées-sorties indépendantes des threads, ce qui est une boîte de vers complètement différente. :)

Pour plus d'informations sur ce sujet, je recommande fortement le chapitre 8, Système d'E / S, de Windows Internals 6e édition, de Mark Russinovich, Margosis, et al.

** Edit: ** J'ai finalement trouvé la base de connaissances officielle pour cette erreur: http://support.microsoft.com/kb/2819485/EN-US

L'opération d'E / S doit être réessayée 8 fois, une fois par minute, jusqu'à ce que Windows abandonne.

Modifier: comme promis: http://blogs.msdn.com/b/ntdebugging/archive/2013/04/30/interpreting-event-153-errors.aspx

Non, il y aurait un message différent et (espérons-le) l'une des couches d'application lèverait une exception si elle ne réussissait pas à enregistrer les données.

Avant Windows Server 2012 (ou le correctif 2819485 si sur Windows Server 2008 R2), le système réessayait silencieusement lorsque ces délais d'attente se produisaient. Le but du message est d'augmenter la visibilité de ces événements. Ils peuvent indiquer un problème de capacité ou un défaut du pilote, et dans le cas d'iSCSI, d'autres défauts du système d'exploitation peuvent être attribués au retard.

Dans le cas du stockage externe (non attaché directement), certains fournisseurs dans le passé ont augmenté la valeur du délai d'attente, par exemple à 60 secondes. Cependant, étant donné le nombre par défaut de nouvelles tentatives par des composants de couche supérieure tels que l'initiateur iSCSI, cela peut signifier que plusieurs minutes peuvent s'écouler avant que le système n'initie un basculement. Ce serait évidemment un comportement sous-optimal.

Plus d'information:

Entrées de registre pour les pilotes de miniport SCSI
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 a publié une mise à jour qui permet de spécifier le seuil pour les opérations storport.sys.

Après avoir installé cette mise à jour, vous pouvez enregistrer un événement lorsque le temps de latence pour les E / S vers le stockage est égal ou supérieur à un seuil. La valeur seuil peut être définie par l'utilisateur. Cette opération est effectuée au niveau du pilote d'adaptateur afin que vous puissiez voir s'il existe un problème de performances sur le SAN. Ensuite, vous pouvez contacter un fournisseur de stockage pour résoudre le problème.

Remarque: cette mise à jour restaure les fonctionnalités fournies dans Windows 7 et Windows Server 2008 R2. Lorsque la fonctionnalité est activée, la valeur de seuil est mesurée en 100 nanosecondes (0,0001 millisecondes). En outre, les valeurs suivantes sont enregistrées dans l'événement:

BuildIoDuration : durée que le MINIPORT a passé dans la fonction d'E / S de génération pour cette demande StartIoDuration : durée que le MINIPORT a passé dans la fonction d'E / S de démarrage pour cette demande DataTransferLength : taille du transfert en octets

Mise à jour qui améliore les capacités de journalisation du pilote Storport.sys dans Windows Server 2012
http://support.microsoft.com/kb/2819476

Mise à jour cumulative de Windows 8 et Windows Server 2012: avril 2013
http://support.microsoft.com/kb/2822241

Peut-être un message tardif, mais j'ai constaté qu'il peut être causé par VSS. Nous avions un client qui exécutait veeam mais avait oublié de désactiver le serveur Windows (le disque a été retiré). Cela a causé une foule de problèmes et cette erreur était la principale.

Arrêté la sauvegarde et wham, aucune erreur.