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