En full local-lvm tar med seg hele Proxmox-verten i fallet. Gjestene fryser, backup feiler, og du merker det som regel først når du står midt oppe i noe helt annet. For en stund siden krøp lagringen mot taket igjen. Utnyttelsen lå rundt 80 prosent og steg jevnt og trutt. Her er de tre årsakene, og hva som faktisk fikset dem.
Tre årsaker

Det var ikke én stor synder her, men tre små som hadde samlet seg opp over tid.
- Døde eller ubrukte LXC-containere. Gamle testcontainere jeg aldri fikk slettet, men som fortsatt satt på thin-volumene sine.
- Ugjenvunnet thin-provisionert plass. Når en gjest sletter filer inni seg selv, sendes ikke blokkene automatisk tilbake til poolen. Poolen går rundt og tror plassen fortsatt er i bruk.
- Journald-logger uten tak. Systemloggen får vokse fritt til den har spist seg gjennom flere gigabyte.
Den midterste er den lumske. Ugjenvunnet plass dukker aldri opp som noe du kan slette. Filene er borte inne i gjesten, men poolen ser dem fortsatt som allokert. Du kan lete etter store filer så lenge du orker uten å finne noe som helst. Plassen må trimmes tilbake, ikke slettes.
Fiks 1: Slett det som ikke brukes
Finn containerne som ikke lenger har en jobb å gjøre, og fjern dem. Først en titt på hva som finnes og hvor mye hvert volum legger beslag på:
pct list
lvs -o lv_name,data_percent,lv_size
# fjern en container du er sikker på
pct destroy <CTID> --purge
Fiks 2: Slå på discard og trim tilbake plassen

For at TRIM skal virke i det hele tatt, må diskene i gjestene ha discard aktivert. Sett det på hvert relevante volum, og kjør så fstrim for å levere de frie blokkene tilbake til poolen.
# aktiver discard på en disk (LXC eller VM)
pct set <CTID> -rootfs volume=local-lvm:vm-<CTID>-disk-0,discard=1
# trim alle monterte filsystemer nå
fstrim -av
Det er dette steget som gjør mest av jobben. Idet fstrim er ferdig, faller data_percent på poolen med en gang, uten at du har rørt en eneste fil.
Fiks 3: Cap journald
Sett et hardt tak på systemloggen, så den aldri får spise mer enn du har tenkt å gi den. Rediger journald.conf:
# /etc/systemd/journald.conf
[Journal]
SystemMaxUse=500M
systemctl restart systemd-journald
journalctl --disk-usage
Automatiser trimmingen
En engangstrim redder dagen, men ikke uken. Plassen lekker sakte tilbake så lenge gjestene fortsetter å slette filer. Løsningen er å la fstrim gå ukentlig via en timer:
systemctl enable --now fstrim.timer
systemctl list-timers fstrim.timer
Resultat
Utnyttelsen gikk fra rundt 80 til 56 prosent. Ingen containere som betydde noe ble rørt, og ingen data forsvant. Brorparten av gevinsten kom fra trimmingen, ikke slettingen.
Lærdommen er enkel nok. Hold et øye med local-lvm, slå på discard fra dag én, og la en ukentlig timer holde poolen ren av seg selv. En full pool er en driftshendelse som stopper alt, og den er billig å forebygge når man først vet hvor den kommer fra.



