Intereting Posts
Fedora 16 для Fedora 17 после обновления Объясните вывод значений -D в GNU find Как записывать в каталог как часть сценария оболочки и делать число слов в файлах? правильный способ перебора содержимого в каталоге Применить команду между разными именами каталогов экспортировать HTTP_PROXY и специальные символы в passwd Имена сетевого интерфейса, выводимые из ifconfig Добавить два пробела в переменную Как создать файлы истории с датой, автоматически присоединенной? Копия SCP через SSH не работает – в разрешении отказано, и stdin не является tty выполнение сценария sh из cron С полным журналированием данных, почему данные появляются в каталоге немедленно? Проблемы с локалью; не может заставить Arch Linux использовать UFT-8 Строка Shebang с `#! / Usr / bin / env command -argument` не работает в Linux Как загружаются initramfs, если он находится на файловой системе, которую он должен разблокировать?

Уменьшить время повторного запуска / ожидания в Ubuntu

Как уменьшить время ожидания ввода-вывода и повторить попытку, чтобы ОС не пыталась постоянно записывать диск с ошибкой?

У меня есть система, которую я использую для создания копий демонстрационного контента, который заимствован для клиентов на обычных жестких дисках SATA. Мы подключаем сразу несколько дисков через SAS и копируем их с помощью сценария.

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

Я не забочусь о восстановлении плохих дисков. Мне просто нужно отгонять их, чтобы они не замедляли все остальное.

Я также изучаю badblocks и smartmontools и рассматриваю возможность предварительной проверки на дисках перед тем, как начать писать.

ОС: Ubuntu Linux (12.04 lts)

Я не использовал эту настройку раньше, но вы, вероятно, захотите настроить eh_timeout (тайм-аут обработки ошибок) для данного диска:

 [root@localhost device]# cat /sys/block/sda/device/eh_timeout 10 [root@localhost device]# 

Вышеуказанное значение sda установлено sda 10 секундам. Из базы знаний Red Hat:

В некоторых конфигурациях хранения (например, конфигурации со многими LUN) код обработки ошибок SCSI может потратить большое количество времени на выдачу команд, таких как TEST UNIT READY, на невосприимчивые устройства хранения. В объект устройства SCSI добавлен новый параметр sysfs, eh_timeout, который позволяет настроить значение таймаута для команд TEST UNIT READY и REQUEST SENSE, используемых кодом обработки ошибок SCSI. Это уменьшает количество времени, затрачиваемого на проверку этих невосприимчивых устройств. Значение по умолчанию eh_timeout составляет 10 секунд, это значение таймаута, используемое до добавления этой функции.

Monitor /sys/block/<dev>/stat для интересующих вас устройств и сравните 10-й параметр (io_ticks).

например, ticks = io_ticks - prev_ticks / seconds_deltatime / 10

Это процент доступного времени, которое диск потратил на ожидание диска io.

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

См. Документацию по блочному уровню .

Просто используйте что-то вроде Munin и нарисуйте его. Вы можете получить Munin, чтобы предупредить, если он превышает пороговое значение, например, 90% или независимо от того, что показывает ваш график, является хорошим показателем предупреждения.

например, см. эти два графика Munin, показывающие, что / dev / sdi нужно смотреть. В этом примере, если / dev / sdi является частью массива, из-за этого пострадает весь массив.

Использование диска на устройство - по дням

Использование диска на устройство - по неделям

Если вы посмотрите график недели, вы увидите, что / dev / sdc также может быть медленным.

Я должен добавить, что / dev / sdi выше не сломан, это всего лишь медленный диск (на самом деле зеленый диск, который кто-то добавил в массив дисков SATA для корпоративного уровня), которые замедляли работу массива. Фактический сбойный диск будет торчать как больной палец.

В общем, я бы, вероятно, пошел со сценарием, если бы у меня было время, но Munin, если бы я просто хотел получить быстрое решение и подключиться к серверу, было легко.