SSD-en er på 100 prosent endurance og SMART sier FAILED. Nå hva?

En consumer-NVMe i en homelab meldte plutselig 100 prosent brukt levetid, og SMART hoppet over til FAILED. Disken virket fortsatt helt fint. Det høres ut som en selvmotsigelse, men er det ikke. Det er en advarsel du faktisk har tid til å reagere på, forutsatt at du forstår hva tallene sier.

100 prosent er ikke det samme som død

Ikke stol på det binære PASSED/FAILED-flagget alene. Det forteller deg nesten ingenting. Les rådataene i stedet:

nvme smart-log /dev/nvme0

Fire felter er verdt å bry seg om:

• percentage_used: 100 betyr at du har passert produsentens TBW-estimat. Det er en garantiterskel, ikke et dødstidspunkt. Tallet kan fint krype forbi 100 og fortsette å telle.
• media_errors: skal stå på 0. Er den over 0, har disken faktiske ulesbare blokker. Da haster det for alvor.
• available_spare mot available_spare_threshold: her ligger det virkelige faresignalet. Når spare-poolen nærmer seg terskelen, begynner disken å gå tom for reserveblokker å bytte inn.
• data_units_written: forteller skrivevolum over tid. Gang med 512000 for å få bytes.

En disk på 100 prosent used, med spare på 100 og null media-errors, er sliten men fungerer. En disk med fallende available_spare er derimot på vei ut, uansett hva de andre tallene sier.

Kjøp tid: fjern unødvendig skriving

Mesteparten av slitasjen på en systemdisk kommer fra logg og swap, ikke fra nyttedata. Begge deler kan du dempe uten å røre en eneste skrue.

Sett swappiness lavt, og gjør det varig:

# /etc/sysctl.d/99-swappiness.conf
vm.swappiness=10

sysctl --system

Kutt journald ned til en fast størrelse:

journalctl --vacuum-size=200M

Og lås den samme grensen fast i /etc/systemd/journald.conf, ellers vokser den tilbake:

SystemMaxUse=200M

Flytt så de tunge loggskriverne, databasene og metrics-innsamlingen vekk fra systemdisken og over på et eget volum. Systemdisken skal helst ligge og skrive nesten ingenting.

Overvåk bevegelsen, ikke øyeblikket

Et statisk tall sier deg lite. Det er bevegelsen som betyr noe. Sett opp en daglig sjekk som sier ifra når available_spare synker eller media-errors øker:

nvme smart-log /dev/nvme0 | grep -E \
  'percentage_used|available_spare|media_errors'

Send verdiene til det varselsystemet du allerede har, enten det er push, Discord eller e-post. Poenget er at du fanger opp trenden av seg selv, i stedet for å måtte huske å logge inn og sjekke manuelt.

Den egentlige fiksen: speil

Alt over er tidskjøp. Grunnproblemet er at én enkelt disk uten redundans er ett punkt som feller alt annet. Når den dør, og den dør, står hele systemet.

Løsningen er å speile: ZFS mirror eller RAID1 med to disker. Da kan én disk feile uten nedetid, og du bytter den ut mens systemet kjører videre.

zpool create rpool mirror /dev/nvme0n1 /dev/nvme1n1

Behandle 100 prosent endurance som et vink om at du mangler redundans, ikke som et signal om å få panikk. Fjern det unødvendige skrivet, sett opp overvåking, og planlegg et speil. En disk som fortsatt virker gir deg tid. Bruk den tiden på å slippe å være avhengig av én disk.