/ (/dev/sda1)
54 GB / 80 GB · 67%
/home (/dev/sdb1)
80 GB / 200 GB · 40%
/boot/efi (/dev/sda15)
317 MB / 1 GB · 31%
| Urządzenie | Rozmiar | Model | Kondycja (SMART) | Temp. | Godzin pracy | Sektory realloc |
|---|---|---|---|---|---|---|
sda SSD |
80G | QEMU HARDDISK | OK | 38°C | 14,268 | 0 |
sdb SSD |
200G | Samsung SSD 870 | OK | 34°C | 9,257 | 0 |
Dwa problemy z dyskiem kładą serwery i nie są do siebie ani trochę podobne. Powolny to napęd, który zaczyna odmawiać posłuszeństwa, co SMART zwykle widzi z wyprzedzeniem. Szybki to zapełniający się system plików, który ciągnie za sobą usługi: baza danych, która nie może pisać, to baza danych, która staje.
Ta strona obejmuje oba: zajętość na system plików, atrybuty SMART na napęd i temperaturę. Spośród atrybutów SMART naprawdę zapowiadają awarię tylko liczba sektorów przydzielonych ponownie, sektory oczekujące i nienaprawialne w trybie offline; jeśli któryś z nich oddala się od zera, zamów zamiennik, zamiast czekać na potwierdzenie. Większość pozostałych wartości waha się bez znaczenia.
Wyczerpanie i-węzłów pokazane jest osobno, bo bywa bardzo mylące, gdy nastąpi: dysk zgłasza wolne miejsce, zapisy i tak zawodzą, a nic w oczywistych miejscach tego nie tłumaczy. Przyczyną jest katalog z setkami tysięcy maleńkich plików — dane sesji, kolejka pocztowa, nierotowana pamięć podręczna — który zużywa stały zapas i-węzłów systemu plików, prawie nie ruszając jego pojemności.
Jest i trzecia dyskowa bieda, która niczego nie psuje, a jedynie spowalnia: napęd jest tak zajęty, że procesy stoją do niego w kolejce. W liczbach to I/O wait i rzadko rośnie sam z siebie — zwykle stoi za tym coś zaplanowanego: nocna kopia zapasowa, przebudowa indeksów, pełne skanowanie ClamAV po całym systemie plików. Jeśli serwer ciężknie za każdym razem o tej samej godzinie, szukajcie harmonogramu, a nie awarii.