/ (/dev/sda1)
52 GB / 80 GB · 65%
/home (/dev/sdb1)
72 GB / 200 GB · 36%
/boot/efi (/dev/sda15)
317 MB / 1 GB · 31%
| Enhet | Størrelse | Modell | Helse (SMART) | Temp. | Driftstimer | Realloc-sektorer |
|---|---|---|---|---|---|---|
sda SSD |
80G | QEMU HARDDISK | OK | 38°C | 14,257 | 0 |
sdb SSD |
200G | Samsung SSD 870 | OK | 31°C | 9,235 | 0 |
To diskproblemer legger servere ned, og de likner ikke på hverandre i det hele tatt. Det langsomme er en disk som begynner å svikte, noe SMART som regel ser komme. Det raske er et filsystem som fylles og drar tjenestene med seg: en database som ikke får skrive er en database som stopper.
Denne siden dekker begge: bruk per filsystem, SMART-attributter per disk og temperatur. Av SMART-attributtene er det bare antall omfordelte sektorer, ventende sektorer og offline ikke-korrigerbare som virkelig varsler havari; beveger noen av dem seg bort fra null, bestill erstatning i stedet for å vente på bekreftelse. De fleste andre verdiene svinger uten betydning.
Tomme for inoder vises separat, fordi det er så forvirrende når det skjer: disken melder ledig plass, skrivinger mislykkes likevel, og ingenting på de opplagte stedene forklarer det. Årsaken er en katalog med hundretusenvis av bittesmå filer — øktdata, e-postkø, en cache som aldri ble rotert — som bruker opp filsystemets faste beholdning av inoder uten å røre kapasiteten nevneverdig.
Det finnes en tredje diskplage også, en som ikke ødelegger noe og bare bremser: stasjonen er så opptatt at prosesser står i kø til den. I tall er det I/O wait, og den stiger sjelden av seg selv — bak ligger som regel noe planlagt: nattens sikkerhetskopi, en indeksgjenoppbygging, en fullstendig ClamAV-gjennomgang av hele filsystemet. Blir tjeneren tung på samme time hver gang, let etter en tidsplan og ikke etter en feil.