Skróć czas ponownych prób / oczekiwania na złe blokowanie w Ubuntu

Jak mogę skrócić czas oczekiwania IO i ponowić próbę, aby system operacyjny nie próbował ciągle zapisywać na uszkodzonym dysku?

Mam system, którego używam do tworzenia kopii treści demonstracyjnych, które są pożyczane klientom na zwykłych komputerowych dyskach twardych SATA. Łączymy wiele dysków jednocześnie za pośrednictwem SAS i kopiujemy do nich zawartość za pomocą skryptu.

Ponieważ dyski są wypożyczone, czasami niektóre wrócą uszkodzone, ale nie wiem, czy są uszkodzone, więc następnym razem, gdy dysk zostanie ponownie użyty w operacji kopiowania, spowalnia inne dyski, gdy system próbuje IO na tym dysku. Czasami zauważenie nieprawidłowego dysku i usunięcie go może potrwać kilka godzin. Po usunięciu dysku pozostałe dyski zaczynają pisać z normalną prędkością.

Nie dbam o odzyskiwanie złych dysków. Muszę je tylko usunąć, żeby nie spowalniały wszystkiego innego.

Badam też badblocks i smartmontools i zastanawiam się nad napisaniem wstępnej kontroli dysków, zanim zacznę pisać.

System operacyjny: Ubuntu Linux (12,04 lts)

Nie korzystałem wcześniej z tego przestrajania, ale prawdopodobnie chcesz dostosować eh_timeout (limit czasu obsługi błędów) dla danego napędu:

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

Powyższe pokazuje sdaustawiony na 10 sekund. Z bazy wiedzy Red Hat:

W niektórych konfiguracjach pamięci masowej (na przykład w konfiguracji z wieloma jednostkami LUN) kod obsługi błędów SCSI może poświęcić wiele czasu na wydawanie poleceń, takich jak GOTOWA JEDNOSTKA TESTOWA, na niereagujące urządzenia pamięci masowej. Dodano nowy parametr sysfs, eh_timeout, do obiektu urządzenia SCSI, który umożliwia konfigurację wartości limitu czasu dla komend TEST UNIT READY i REQUEST SENSE używanych przez kod obsługi błędów SCSI. Zmniejsza to czas spędzony na sprawdzaniu tych nieodpowiadających urządzeń. Domyślna wartość eh_timeout to 10 sekund, która była wartością limitu czasu używaną przed dodaniem tej funkcji.

Monitoruj /sys/block/<dev>/staturządzenia, które Cię interesują, i porównaj 10. parametr (io_ticks).

na przykład, ticks = io_ticks - prev_ticks / seconds_deltatime / 10

Jest to procent dostępnego czasu, jaki dysk spędził na oczekiwaniu na dysk io.

Oczywiście blisko 100% byłoby warte sprawdzenia, w przeciwnym razie bądź naprawdę sprytny i porównaj go ze średnią wszystkich dysków i wybierz dowolny dysk (dyski) powyżej średniej.

Zobacz dokumentację statystyk warstwy blokowej .

W przeciwnym razie użyj czegoś takiego jak Munin i zrób to na wykresie. Możesz sprawić, by Munin zaalarmował, jeśli przekroczy próg, np. 90% lub cokolwiek, co pokazuje twój wykres, jest dobrym sygnałem ostrzegawczym.

np. zobacz te dwa wykresy Munin pokazujące, że / dev / sdi musi się przyjrzeć. W tym przykładzie, jeśli / dev / sdi jest częścią tablicy, cała tablica ucierpiałaby z tego powodu.

Jeśli spojrzysz na wykres tygodnia, zobaczysz, że / dev / sdc może być również powolny.

Powinienem dodać, że powyższy / dev / sdi nie jest zepsuty, to po prostu wolny dysk (właściwie zielony dysk, który ktoś dodał do macierzy dysków sata klasy korporacyjnej), co spowolniło macierz. Rzeczywisty uszkodzony dysk wystaje jak obolały kciuk.

Podsumowując, prawdopodobnie miałbym skrypt, gdybym miał czas, ale Munin, gdybym chciał tylko szybkiego rozwiązania, a połączenie z serwerem było łatwe.