Que signifie "L'opération IO à 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 plusieurs trajets IO serveur configuré 2012 blade qui affiche des avertissements comme ceux-ci lors de l'échec du chemin MPIO:
L'opération IO à l'adresse de bloc logique 0 pour le disque 7 a été réessayée.
Je sais ce qui provoque l'avertissement, je ne recherche donc pas la cause, mais que signifie réellement ce message?
Est-ce à dire que si ceci IO était une opération d'écriture, alors le serveur a réellement perdu les données qu'il essayait d'écrire?
Merci pour toute lumière que vous pouvez faire 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 tout IO operation, le gestionnaire IO 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. Disons 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 remarquerez peut-être 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 IO 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 1a2b3c4d, où vous avez précédemment trouvé cette adresse en exécutant la commande kd> !process 8f7d6c4a qui listera tous les IRP associés aux threads associés à ce processus. kd> !process 0 0 pour 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 dernier pilote qui a géré l'IRP, car il aura un > le pointant dans la liste. Ensuite, pour obtenir plus d'informations sur ce que ce pilote faisait avec cet IRP, effectuez une kd> !devobj 1a2b3c4d5e6f où c'est l'adresse réelle de l'objet périphérique.
Ensuite, faites un kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATA en utilisant 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 soit relancée depuis le début, et elle ne sera considérée comme terminée que lorsque le gestionnaire IO le dira).
Oh, et il y a aussi un thread-agnostique IO qui est un complètement 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 IO 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
Microsoft a publié une mise à jour qui permet de spécifier le seuil des 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 requête 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é supprimé). Cela a causé une foule de problèmes et cette erreur était la principale.
Arrêté la sauvegarde et wham, aucune erreur.