Oplossingen voor 'No space left on device' in Linux: Diagnose van schijf, inode en verwijderde bestanden
AI_Manager
Wanneer de foutmelding No space left on device optreedt in Linux, denkt men meestal direct dat de schijf vol is. De werkelijke oorzaak kan echter niet alleen een tekort aan schijfblokken zijn, maar ook uitputting van inodes, bestanden die zijn verwijderd maar nog steeds door een proces worden bezet, mislukte mounts of plotseling toegenomen logs.
Als je zonder onderzoek bestanden begint te verwijderen met rm -rf, kun je logs verliezen die nodig zijn voor foutanalyse of kan de dienst nog verder uitvallen. In dit artikel bespreken we de diagnosevolgorde en veilige oplossingen die bruikbaar zijn op gangbare Linux-servers zoals Rocky Linux, RHEL, CentOS en Ubuntu.

No space left on device: 5 commando’s om als eerste uit te voeren
Als je weinig tijd hebt, controleer dan de volgende volgorde. Voer bij /path een bestaande map in die zich op hetzelfde bestandssysteem bevindt als het pad waar de fout optrad. Als het aanmaken van het bestand zelf is mislukt en het doelbestand niet bestaat, gebruik dan de dichtstbijzijnde bovenliggende map.
# 1. Controleer tot welk bestandssysteem het pad met de fout behoort
findmnt -T /path
# 2. Controleer het schijfblokgebruik van het bestandssysteem
df -hT /path
# 3. Controleer het inode-gebruik
df -i /path
# 4. Controleer mappen met een grote capaciteit binnen hetzelfde bestandssysteem
sudo du -xhd1 /path 2>/dev/null | sort -h
# 5. Controleer bestanden die zijn verwijderd maar nog geopend zijn door een proces
sudo lsof +L1 2>/dev/null
Let op: du en find kunnen de schijf-I/O verhogen op servers met veel bestanden. Voer ze uit terwijl je de belasting van de productieservice in de gaten houdt en beperk het bereik.
Belangrijkste oorzaken van ‘No space left on device’
| Oorzaak | Typische symptomen | Commando voor eerste controle |
|---|---|---|
| Tekort aan schijfblokken | Use% is 100% of nadert de drempelwaarde |
df -hT |
| Uitputting van inodes | Er is nog capaciteit, maar er kunnen geen nieuwe bestanden worden aangemaakt | df -i |
| Verwijderde geopende bestanden | Bestanden zijn verwijderd, maar het gebruik van df neemt niet af |
lsof +L1 |
| Plotselinge toename van logs/cache | /var of het root-bestandssysteem groeit snel |
du, journalctl --disk-usage |
| Mislukte mount | Gegevens van een apart schijfpad worden opgeslagen in het root-bestandssysteem | findmnt -T, lsblk -f |
Diagnose 1 voor ‘No space left on device’: Controleer het gebruik van schijfblokken
df -hT
df -hT /var/log
df toont de totale grootte, het gebruik, de vrije ruimte, het gebruikspercentage en de mount-locatie per bestandssysteem. -h geeft de uitvoer weer in een voor mensen leesbare eenheid, en -T toont ook het type bestandssysteem zoals XFS of ext4. Controleer naast Use% ook de waarde Avail, die aangeeft wat een normale gebruiker daadwerkelijk kan gebruiken. Vanwege gereserveerde blokken in ext4 kan er voor een normale gebruiker geen ruimte zijn, terwijl er voor root nog wel wat ruimte over is.
Beoordeel niet alleen op basis van de algemene resultaten, maar specificeer een bestaande map op hetzelfde bestandssysteem als het pad waar het schrijven daadwerkelijk mislukte als argument. Als een applicatie bijvoorbeeld niet kan schrijven naar /data/app.log, is het bestand mogelijk niet aangemaakt; controleer daarom de bestaande bovenliggende map /data.
findmnt -T /data
df -hT /data
Zelfs als er vrije ruimte is op het root-bestandssysteem, kun je in dat pad geen bestanden aanmaken als /data een apart bestandssysteem is dat vol is.
Diagnose 2 voor ‘No space left on device’: Controleer het inode-gebruik
df -i
df -i /var
Inodes zijn datastructuren die metadata beheren zoals bestandsrechten, eigenaar, grootte, tijdinformatie en de locatie van gegevens. Als er zeer veel kleine bestanden worden aangemaakt, kunnen de beschikbare inodes opraken, zelfs als er nog schijfruimte over is. Bij ext4 wordt het aantal inodes bepaald bij het aanmaken van het bestandssysteem, terwijl XFS inodes dynamisch toewijst. Echter, ook bij XFS kan het aanmaken van nieuwe bestanden mislukken als er onvoldoende ruimte is voor gegevens of metadata, dus beoordeel df -i en df -hT in samenhang.
Als IUse% 100% is, is het effectiever om veel onnodige kleine bestanden op te ruimen dan om een paar grote bestanden te verwijderen. Mappen met een groot aantal bestanden kunnen worden gevonden met het volgende commando.
# Controleer mappen met veel bestanden binnen een bestandssysteem zoals /var
sudo find /var -xdev -type f -printf '%h\n' 2>/dev/null \
| sort | uniq -c | sort -nr | head -n 30
Bestanden die in grote hoeveelheden worden aangemaakt, zoals sessiebestanden, applicatiecaches, mailwachtrijen en tijdelijke bestanden, zijn veelvoorkomende oorzaken. Controleer altijd de bewaartermijn en de impact op de service voordat u ze verwijdert.
Diagnose van No space left on device 3: Grote mappen en bestanden vinden
Als het root-bestandssysteem vol is, controleer dan eerst het gebruik per hoofdmap en navigeer stap voor stap naar de mappen met de grootste omvang.
sudo du -xhd1 / 2>/dev/null | sort -h
sudo du -xhd1 /var 2>/dev/null | sort -h
sudo du -xhd1 /var/log 2>/dev/null | sort -h
-x voorkomt dat het commando overgaat naar andere bestandssystemen. -d1 geeft alleen de resultaten weer voor mappen tot één niveau dieper. Omdat het commando nog steeds door alle submappen en bestanden loopt om de totalen te berekenen, vermindert deze optie op zichzelf de hoeveelheid zoekwerk of I/O niet. De werking per optie is terug te vinden in de officiële GNU du-handleiding.
Hieronder volgt een voorbeeld voor het vinden van bestanden groter dan 1GB op een specifiek bestandssysteem.
sudo find /var -xdev -type f -size +1G \
-printf '%s %p\n' 2>/dev/null \
| sort -nr | head -n 30
De paden die meestal gecontroleerd moeten worden zijn /var/log, /var/cache, /tmp, /home, /opt en /var/lib/docker. Let er echter op dat het handmatig verwijderen van bestanden onder /var/lib de database of container-runtime kan beschadigen; gebruik daarom altijd de officiële opschoonprocedures van de betreffende service.
Diagnose van No space left on device 4: Verwijderde open bestanden controleren
In Linux worden datablokken niet direct vrijgegeven wanneer een bestandsnaam wordt verwijderd als een draaiend proces het bestand nog open heeft staan. Het bestand is niet meer zichtbaar in de map en wordt daarom niet meegeteld door du, maar het blijft ruimte innemen in df totdat de file descriptor wordt gesloten.
sudo lsof +L1 2>/dev/null
# Controleer te beginnen bij items met de grootste capaciteit
sudo lsof +L1 2>/dev/null \
| awk 'NR>1 {print $7, $1, $2, $4, $9}' \
| sort -nr | head -n 30
Controleer in de uitvoer de procesnaam, PID, file descriptor en de grootte. De oplossing is om de service die het bestand bezet houdt op de juiste manier te herstarten of de applicatie het bestand opnieuw te laten openen.
sudo systemctl restart 서비스명
sudo lsof +L1 2>/dev/null
df -hT
Op productieservers moet u eerst de redundantie van de service en de impact controleren. Het beëindigen van processen met kill -9 of het geforceerd leegmaken van /proc/PID/fd zonder de oorzaak te kennen, kan leiden tot gegevensverlies en storingen en wordt daarom niet aanbevolen als eerste maatregel.
5. Als de systemd journal-logs te groot zijn
journalctl --disk-usage
Als het systemd journal veel ruimte in beslag neemt, kunt u oude logs opruimen op basis van grootte of tijdsduur.
# Zet actieve logboeken eerst over naar de archiefstatus en ruim archieflogboeken op tot 500 MB of minder
sudo journalctl --rotate --vacuum-size=500M
# Archieflogboeken ouder dan 14 dagen opschonen
sudo journalctl --vacuum-time=14d
De optie --vacuum-* is van toepassing op gearchiveerde journal-bestanden. Om ook actieve logs direct op te schonen, is het effectiever om dit te combineren met --rotate.
Om herhaling te voorkomen, kunt u het maximale gebruik van het journal beperken in overeenstemming met uw distributie en operationeel beleid.
# /etc/systemd/journald.conf.d/10-size-limit.conf
[Journal]
SystemMaxUse=1G
RuntimeMaxUse=256M
sudo systemctl restart systemd-journald
journalctl --disk-usage
Als u niet bekend bent met de structuur van systemd-services, kunt u ook het artikel over het maken en configureren van Systemd-services raadplegen.
6. Wanneer een mount is weggevallen en data op de root-schijf wordt opgeslagen
Als /data een aparte opslaglocatie zou moeten zijn, maar niet is gemount door een opstartfout of netwerkprobleem, kan de applicatie data blijven schrijven naar het root-bestandssysteem op hetzelfde pad.
findmnt -T /data
lsblk -f
systemctl --failed
journalctl -b -u '*.mount'
In dit geval moet u niet eerst de bestanden verwijderen, maar de schrijfacties van de applicatie stoppen en de mount-status van het oorspronkelijke bestandssysteem herstellen. Voor het controleren van bestanden die onder de mount verborgen zijn, is een onderhoudsprocedure vereist waarbij de impact op de service en de gegevensintegriteit worden beoordeeld.
Waarom de capaciteit van df en du verschilt
df rapporteert het gebruik op basis van de blokken die door het bestandssysteem zijn toegewezen, terwijl du het gebruik berekent door door de bestanden te lopen die toegankelijk zijn in de huidige mappenstructuur. Daarom kunnen de waarden in de volgende situaties verschillen:
- Bestanden die zijn verwijderd maar nog steeds openstaan door een proces
- Metadata van het bestandssysteem en gereserveerde gebieden
- Mappen die
duniet kon lezen vanwege ontbrekende rechten - Andere bestandssystemen die op subpaden zijn gemount
- Gedeelde blokken in snapshots en Copy-on-Write bestandssystemen
Als het verschil tussen df en du groot is, is het raadzaam om eerst de lsof +L1 en de mount-structuur te controleren.
Herstelvolgorde voor No space left on device op productieservers
- Controleer het foutpad: Controleer welk pad en bestandssysteem de applicatie daadwerkelijk gebruikt.
- Beperk de oorzaak van de toename: Stop eerst de oorzaak die de capaciteit blijft vergroten, zoals log-explosies of repetitieve taken.
- Bewaar bewijs van de storing: Sla de benodigde logs en statusinformatie op een aparte locatie op voordat u gaat opschonen.
- Opschonen via officiële procedures: Gebruik bij voorkeur logrotate, journal vacuum of de ingebouwde cache-opschoonfuncties van de applicatie.
- Verifieer het herstel: Controleer opnieuw het schijf- en inode-gebruik, het aanmaken van bestanden, de servicestatus en de applicatielogs.
df -hT /path
df -i /path
touch /path/.write-test && rm -f /path/.write-test
systemctl --failed
Checklist voor het voorkomen van herhaling
- Monitor niet alleen het schijfgebruik, maar ook het inode-gebruik.
- Maak onderscheid tussen waarschuwings- en kritieke drempelwaarden en observeer ook de snelheid waarmee de capaciteit toeneemt.
- Stel logrotate of een eigen retentiebeleid in voor applicatielogs.
- Beperk de maximale grootte en bewaartermijn van het systemd-journal op basis van het operationele beleid.
- Gebruik voor Docker, databases en back-upoplossingen de opschoonfuncties die door de producten zelf worden aangeboden.
/var/log, scheid data- en back-upgebieden om te voorkomen dat een toename in één gebied leidt tot een algehele OS-storing.- Configureer afhankelijkheden en voorafgaande controles om te voorkomen dat applicaties naar de lokale schijf blijven schrijven wanneer een mount is mislukt.
Veelgestelde vragen
Waarom treedt de foutmelding No space left on device op, terwijl er nog schijfruimte beschikbaar is?
Controleer eerst het inode-gebruik en het bestandssysteem waartoe het daadwerkelijke foutpad behoort. Zelfs als er vrije ruimte is op df -h, kan het aanmaken van bestanden mislukken als df -i 100% is of als een ander mountpunt vol is.
Waarom neemt het schijfgebruik volgens df niet af nadat ik logbestanden heb verwijderd?
De kans is groot dat een proces het verwijderde bestand nog steeds open heeft staan. Gebruik lsof +L1 om te achterhalen welk proces het bestand bezet houdt en herstart de betreffende service op de juiste wijze of zorg dat het bestand opnieuw wordt geopend, zodat de ruimte wordt vrijgegeven.
Mag ik alle bestanden onder /var/log verwijderen?
Dit wordt niet aanbevolen. U kunt de oorzaak van storingen en auditgegevens verliezen, en afhankelijk van de applicatie kunnen er problemen ontstaan met de rechten voor het opnieuw aanmaken van logbestanden. Gebruik logrotate, journalctl vacuum of de specifieke opschoonfuncties voor logs van het product.
Wat moet ik doen als het du-commando te traag is?
-d1 beperkt alleen de uitvoerdiepte, maar het doorlopen van submappen gaat door. Beperk eerst het bestandssysteem en het verdachte pad waar de fout optreedt en voer de zoekopdracht daar uit. -x voorkomt dat andere bestandssystemen worden onderzocht. Sla resultaten op om te voorkomen dat dezelfde boomstructuur herhaaldelijk wordt gescand en voer het onderzoek op servers met een groot aantal bestanden uit tijdens momenten met een lage I/O-belasting.
Samenvatting
Het oplossen van No space left on device in Linux begint niet met het verwijderen van bestanden. Controleer in deze volgorde: het doelbestandssysteem met findmnt, het blokgebruik met df -hT, inodes met df -i, mapgebruik met du en verwijderde open bestanden met lsof +L1.
Nadat de oorzaak is vastgesteld, moeten passende maatregelen worden genomen, zoals het instellen van een logretentiebeleid, het herstarten van services of het herstellen van mounts, om gegevensverlies en herhaling te voorkomen.