У меня есть блейд-сервер 2012 с настройкой многопутевого ввода-вывода, который при сбое пути MPIO показывает предупреждения, подобные следующим:
Операция ввода-вывода по адресу логического блока 0 для диска 7 была повторена.
Я знаю, что вызывает предупреждение, поэтому я не ищу причину, но что на самом деле означает это сообщение?
Означает ли это, что если этот ввод-вывод был операцией записи, то сервер действительно потерял данные, которые он пытался записать?
Спасибо за любой свет, который вы могли пролить на значение этого предупреждающего сообщения.
Нет, это не значит, что данные были потеряны. Это просто означает, что время ожидания IRP (пакета запроса ввода-вывода) истекло, пока система ввода-вывода ждала его завершения, и поэтому была предпринята повторная попытка. Когда поток начинает любую операцию ввода-вывода, диспетчер ввода-вывода создает пакет IRP для представления операции по мере ее прохождения через систему.
IRP сохраняется в своем исходном состоянии в буферном / временном списке, чтобы его можно было повторить, если он не удастся в первый раз. Это обеспечивает атомарность, которую можно ожидать от любой транзакционной системы, поэтому мы можем быть более уверены в том, что вы не получите кучу поврежденных или неполных данных, записанных на ваш диск.
Это событие имеет смысл в случае отказа MPIO. Скажем, Windows пытается прочитать или записать что-то из хранилища SAN. Запрос отправлен, и в то же время я перерезаю один из кабелей к SAN. Этот запрос никогда не будет завершен, поэтому Windows попытается выполнить запрос еще раз, только на этот раз запрос будет следовать по другому пути.
Эти события также происходят, когда диски перегружены или просто очень медленно. Вы могли заметить, что эти сообщения совпадают с запланированным резервным копированием и т. Д. Диск мог быть медленным и занятым, а время ожидания некоторого случайного IRP истекло, и ему пришлось попробовать снова. IRP может застрять в подпрограмме обслуживания прерывания, отложенном вызове процедуры или в чем-то еще.
Я мог видеть, что наличие большого количества драйверов фильтра ввода-вывода в вашем стеке также усугубляет эту проблему.
Дело не в том, что такое поведение не происходило точно так же в предыдущих версиях 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 находится в самоволке слишком долго, время ожидания истекает и повторяется с самого начала. Это может быть вызвано очень многими вещами ... даже случайным космическим лучом. Но важно то, что транзакция будет повторена с самого начала и не будет считаться завершенной, пока менеджер ввода-вывода не скажет об этом.
О, и есть также независимый от потоков IO, который является полностью разные банки с червями. :)
Для дальнейшего чтения по этой теме я очень рекомендую главу 8 «Система ввода-вывода» шестого издания «Внутренние компоненты Windows» от Марка Руссиновича, Маргозиса и др.
** Изменить: ** Я наконец нашел официальный КБ для этой ошибки: 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
Корпорация Майкрософт выпустила обновление, которое позволяет указывать пороговое значение для операций 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 (диск был удален). Это вызвало массу проблем, и эта ошибка была основной.
Остановил бэкап и бух, ошибок нет.