Скоротити поганий час повторного / повторного блокування в Ubuntu

Як я можу скоротити час очікування вводу-виводу та повторення спроб, щоб ОС не намагалася постійно записувати на несправний диск?

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

Оскільки накопичувачі здаються в оренду, іноді деякі повертаються пошкодженими, але я не знаю, що вони пошкоджені, тому наступного разу, коли цей диск буде повторно використаний в процесі копіювання, він уповільнює інші диски, коли система повторно завантажує IO на цей диск. Іноді це може зайняти години, перш ніж я помічу поганий диск і видаляю його. Після вилучення накопичувача решта дисків починають писати з нормальною швидкістю.

Мене не хвилює відновлення поганих дисків. Мені просто потрібно відпалити їх, щоб вони не сповільнили все інше.

Я також досліджую неполадки та smartmontools та розглядаю можливість попередньої перевірки на накопичувачах, перш ніж почати писати.

ОС: Ubuntu Linux (12,04 lts)

Я не використовував цю налаштування раніше, але ви, ймовірно, хочете відрегулювати eh_timeout ( час виправлення помилок) для диску, про який йде мова:

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

Вищевказані шоу sdaвстановлені на 10 секунд. З бази знань Red Hat:

У певних конфігураціях сховища (наприклад, конфігурації з багатьма LUN) код обробки помилок SCSI може витратити велику кількість часу, видаючи команди, такі як TEST UNIT READY, на невідповідальні пристрої зберігання даних. До об’єкта пристрою SCSI додано новий параметр sysfs, eh_timeout, який дозволяє конфігурувати значення тайм-ауту для команд TEST UNIT READY та REQUEST SENSE, використовуваних кодом обробки помилок SCSI. Це зменшує кількість часу, витраченого на перевірку цих невідповідальних пристроїв. Значення за замовчуванням eh_timeout становить 10 секунд, що було значенням тайм-ауту, який використовувався до додавання цієї функціональності.

Монітор /sys/block/<dev>/statпристроїв, які вас цікавлять, та порівняйте 10-й параметр (io_ticks).

наприклад, ticks = io_ticks - prev_ticks / seconds_deltatime / 10

Це відсоток доступного часу, який диск витратив на очікування диска io.

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

Дивіться документацію щодо статистики рівня блоків .

Ще використовуйте щось на кшталт Муніна і графікуйте це. Ви можете примусити Муніна оповістити, якщо він перевищує поріг, наприклад, 90% або все, що показує ваш графік, є гарною цифрою попередження.

наприклад, дивіться ці два графіки Муніна, що показують, що / dev / sdi потрібно дивитись. У цьому прикладі, якщо / dev / sdi є частиною масиву, через це постраждає весь масив.

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

Я повинен додати, що / dev / sdi вище не зламаний, це лише повільний диск (власне зелений диск, який хтось додав до масиву корпоративних дискових сата), який уповільнив масив. Фактичний невдалий диск буде стирчати, як біль.

Підсумовуючи це, я, мабуть, пішов би зі сценарієм, якби мав час, але Мунін, якби я просто хотів швидкого рішення, і підключення до сервера було легко.