То, что делает “Операцию IO в логическом адресе блока # для Диска #, было повторено”. имейте в виду при наблюдении в журнале событий Windows Server System?
Я собираюсь предположить, что Вы спрашиваете об установке сервера DNS для ответа authoritive зональную информацию для домена. Если Ваша установка сервера только, чтобы сделать определение имен для клиентов, существует другой набор соображений.
В установке ISP, где существует много доменов, которые могут быть размещены, выполнив Ваш собственный DNS, могло бы быть выгодным. Прямой доступ к конфигурациям будет доступен, и может быть легко интегрирован в любую систему, которую Вы используете для управления доменами клиента, такими как Virtualmin или этажерка. Оборотные стороны - то, что необходимо управлять собственным сервером DNS, таким образом, обновления системы защиты и конфигурация, дублирование и все другие забавные операции, которые идут с обслуживанием сервера. Хотя ISPs обычно размещают веб-серверы так или иначе, так обычно не грандиозное предприятие.
Для исключительного сайта я обычно шел бы с использованием Вашего регистратора или хостинговой компании. Обе организации будут обычно иметь намного больше резервирования системы затем, можно пристроить. Большинство обеспечивает достаточно параметров конфигурации для всех кроме самой сложной из установок.
Нет, это не означает, что данные были потеряны. Это просто означает, что время ожидания 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, потому что он будет иметь a > , указывающий на него в списке. Затем, чтобы получить дополнительную информацию о том, что драйвер делал с этим IRP, выполните kd>! DevObj 1a2b3c4d5e6f , где это фактический адрес объекта устройства.
Затем выполните kd> dt 0x1a2b3c3c2b1a _CLASS_PRIVATE_FDO_DATA , используя адрес полученной вами структуры PrivateFdoData.
Теперь вы готовы сбросить структуру данных AllTransferPacketsList, полученную от PrivateFdoData.
Идея в том, что вы отслеживаете, какой драйвер и что делал с IRP в последний раз, когда он был замечен. Если IRP находится в самоволке слишком долго, время ожидания истекает и повторяется с самого начала. Это может быть вызвано очень многими вещами ... даже случайным космическим лучом. Но важно то, что транзакция будет повторяться с самого начала, и она не будет считаться завершенной до тех пор, пока диспетчер ввода-вывода не сообщит об этом.
О, и есть также поток-независимый ввод-вывод, который полностью разные банки с червями. :)
Для дальнейшего чтения по этой теме я настоятельно рекомендую главу 8, Система ввода-вывода, 6-го издания Windows Internals, от Марка Руссиновича, Маргозиса и др.
** Редактировать: ** Я наконец нашел официальный KB для этой ошибки: 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 : 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 (диск был удален). Это вызвало массу проблем, и эта ошибка была основной.
Остановили резервное копирование и бах, нет ошибки.