Нет, это не значит, что данные были потеряны. Это просто означает, что истекло время ожидания IRP (IO Request Packet), пока система IO дожидалась его завершения, и поэтому была предпринята повторная попытка. Когда поток начинает какую-либо операцию ввода-вывода, менеджер ввода-вывода создает IRP для представления операции при ее прохождении через систему.
IRP сохраняется в своем начальном состоянии в буфере / списке стороннего просмотра, так что его можно повторить, если он потерпит неудачу в первый раз. Это обеспечивает атомарность, которую можно ожидать от любой транзакционной системы, так что мы можем быть более уверены, что вы не получите кучу поврежденных или неполных данных, записанных на ваш диск.
Это событие имеет смысл в случае сбоя MPIO. Скажем, Windows идет читать или писать что-то из хранилища SAN. Запрос отправлен, и в тот же момент я отключил один из кабелей к SAN. Этот запрос никогда не будет выполнен, и Windows попытается выполнить его снова, только на этот раз запрос будет идти по другому пути.
Эти события также происходят, когда диски перегружены или просто очень медленные. Вы можете заметить, что эти сообщения совпадают с запланированными резервными копиями и т. Д. Диск может быть медленным и занятым, а для некоторого случайного IRP истек тайм-аут и пришлось повторить попытку. IRP может застрять в подпрограмме обработки прерывания, или отложенного вызова процедуры, или чего-то еще.
Я мог видеть, что в вашем стеке много драйверов IO-фильтров, что также усугубляет эту проблему.
Дело не в том, что такое поведение происходило не так, как в предыдущих версиях Windows, просто Microsoft явно решила представить эти события в Win8 / Server 2012.
Изменить: Вы можете найти ожидающие IRP потока с помощью отладчика ядра:, kd> !irp 1a2b3c4dгде вы ранее нашли этот адрес, выполнив команду, kd> !process 8f7d6c4aкоторая выведет список всех IRP, связанных с потоками, связанными с этим процессом. kd> !process 0 0перечислить все запущенные процессы.
Как только вы перечислите информацию о IRP с помощью команды! Irp, вы можете легко определить, какой драйвер последний раз обрабатывал IRP, потому что он будет >указывать на него в списке. Затем, чтобы получить больше информации о том, что этот драйвер делал с этим IRP, сделайте, kd> !devobj 1a2b3c4d5e6fгде это фактический адрес объекта устройства.
Затем kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATAиспользуйте адрес полученной вами структуры PrivateFdoData.
Теперь вы готовы сбросить структуру данных AllTransferPacketsList, полученную из PrivateFdoData.
Идея в том, что вы отслеживаете, что водитель делал и что делал с IRP в последний раз, когда его видели. Если IRP слишком долго находится в состоянии AWOL, он истекает и повторяется с самого начала. Это может быть вызвано очень многими вещами ... даже рассеянным космическим лучом. Но важно то, что транзакция будет повторена с самого начала, и она не будет считаться завершенной, пока менеджер ввода-вывода не скажет, что это так.
О, и есть также независимый от потоков ввод-вывод, который представляет собой совершенно другую банку с червями. :)
Для дальнейшего прочтения по этой теме я настоятельно рекомендую главу 8 «Система ввода-вывода» Windows Internals 6th edition, Марк Руссинович, Margosis, et al.
** Редактировать: ** Я наконец-то нашел официальный КБ для этой ошибки: http://support.microsoft.com/kb/2819485/EN-US
Операция ввода-вывода должна повторяться 8 раз, каждую минуту, пока Windows не сдастся.
Изменить: как и было обещано: http://blogs.msdn.com/b/ntdebugging/archive/2013/04/30/interpreting-event-153-errors.aspx