Что означает «операция ввода-вывода по адресу логического блока № для диска №» была повторена », когда она отображается в журнале событий системы Windows Server System?

У меня есть многолучевой IO-сервер, настроенный на блейд-сервер 2012, который отображает предупреждения, подобные приведенным ниже, при сбое пути MPIO

Операция ввода-вывода с адресом логического блока 0 для диска 7 была повторена.

Я знаю, что вызывает предупреждение, поэтому я не ищу причину, но что на самом деле означает это сообщение?

Означает ли это, что если этот ввод-вывод был операцией записи, то сервер фактически терял данные, которые пытался записать?

Спасибо за любой свет, который вы можете пролить на смысл этого предупреждающего сообщения.

Нет, это не значит, что данные были потеряны. Это просто означает, что истекло время ожидания 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

Нет, было бы другое сообщение, и (надеюсь) один из прикладных уровней выдал бы исключение, если ему не удалось успешно сохранить данные.

До Windows Server 2012 (или исправления 2819485, если на Windows Server 2008 R2) система автоматически повторяла попытки при наступлении этих таймаутов. Целью сообщения является повышение видимости этих случаев. Они могут указывать на проблему с емкостью или дефект драйвера, а в случае iSCSI другие дефекты операционной системы могут быть связаны с задержкой.

В случае внешнего (не напрямую подключенного) хранилища некоторые поставщики в прошлом увеличивали значение тайм-аута, например, до 60 секунд. Однако, учитывая количество попыток по умолчанию для компонентов более высокого уровня, таких как инициатор iSCSI, это может означать, что может пройти несколько минут, прежде чем система инициирует отработку отказа. Это, очевидно, было бы неоптимальным поведением.

Больше информации:

Записи реестра для драйверов мини-портов 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 выпустила обновление, которое предоставляет возможность указать порог для операций storport.sys.

После установки этого обновления вы можете регистрировать событие, когда время задержки ввода-вывода в хранилище равно или превышает пороговое значение. Пороговое значение может быть установлено пользователем. Эта операция выполняется на уровне драйвера адаптера, чтобы вы могли увидеть, есть ли проблемы с производительностью в SAN. Затем вы можете обратиться к поставщику хранилища для решения проблемы.

Примечание. Это обновление восстанавливает функциональность, предоставленную в Windows 7 и Windows Server 2008 R2. Когда функция включена, пороговое значение измеряется в 100 наносекунд (0,0001 миллисекунды). Кроме того, в событии регистрируются следующие значения:

BuildIoDuration : продолжительность времени, которое MINIPORT провел в функции ввода-вывода сборки для этого запроса StartIoDuration : продолжительность времени, которую MINIPORT провел в функции начального ввода-вывода для этого запроса DataTransferLength : размер передачи в байтах

Обновление, которое улучшает возможности ведения журнала драйвера Storport.sys в Windows Server 2012
http://support.microsoft.com/kb/2819476

Накопительное обновление для Windows 8 и Windows Server 2012: апрель 2013 г.
http://support.microsoft.com/kb/2822241

Может быть поздний пост, но я обнаружил, что это может быть вызвано с VSS. У нас был клиент, который работал под управлением Veeam, но забыл отключить Windows Server обратно (диск был удален). Это вызвало множество проблем, и эта ошибка была основной.

Остановился и задолбался, ошибок нет.