Vraag df zegt dat schijf vol is, maar dat is het niet


Op een gevirtualiseerde server met Ubuntu 10.04 rapporteert df het volgende:

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             7.4G  7.0G     0 100% /
none                  498M  160K  498M   1% /dev
none                  500M     0  500M   0% /dev/shm
none                  500M   92K  500M   1% /var/run
none                  500M     0  500M   0% /var/lock
none                  500M     0  500M   0% /lib/init/rw
/dev/sda3             917G  305G  566G  36% /home

Dit raadsel mij om twee redenen: 1.) df zegt dat / dev / sda1, gekoppeld aan /, een 7,4 gigabyte capaciteit heeft, waarvan slechts 7,0 gigabytes in gebruik zijn, maar het rapporteert / is 100 procent vol; en 2.) Ik kan bestanden maken op / zodat het duidelijk ruimte over heeft.

Mogelijk relevant is dat de directory / www een symbolische link is naar / home / www, die zich op een andere partitie bevindt (/ dev / sda3, gekoppeld aan / home).

Kan iemand suggesties geven over wat er hier aan de hand is? De server lijkt probleemloos te werken, maar ik wil er zeker van zijn dat er geen probleem is met de partitietabel, bestandssystemen of iets anders dat later tot implosie (of explosie) kan leiden.


47
2017-09-24 20:31


oorsprong


Dank aan allen voor de behulpzame antwoorden. Ik kan geen bestanden maken als normale gebruiker, dus het lijkt erop dat het de buffer van 5 procent is die een catastrofe voorkomt. Nu moet ik er gewoon achter komen waarom de schijf vol is (ik ben een beetje bezorgd dat er iets kwaadaardigs aan de hand is, omdat geen van de logbestanden zoveel ruimte in beslag neemt en er niet veel software is geïnstalleerd, alleen een eenvoudige LAMP-server) ... - Chris
De eerste plaats die ik zou zoeken is / tmp. Een andere mogelijkheid is dat je een verwijderd bestand hebt waar een lopend programma aan vasthoudt. Ik denk dat je 'lsof | grep verwijderd 'als root om die te vinden. - Scott


antwoorden:


Het is mogelijk dat een proces een groot bestand heeft geopend dat sindsdien is verwijderd. Je zult dat proces moeten doden om de ruimte vrij te maken. U kunt het proces mogelijk identificeren door lsof te gebruiken. Op Linux zijn reeds geopende bestanden bekend bij lsof en gemarkeerd als (verwijderd) in de uitvoer van lsof.

U kunt dit controleren met sudo lsof +L1


84
2017-09-27 13:20



Het heeft het mysterie voor mij opgelost. Ik heb een groot logbestand verwijderd van uwsgi zonder de service opnieuw te starten. Bij ondervraging df -ah, Ik heb een schijf vol, maar du -sh / vertelt dat ik vrije ruimte zou moeten hebben. Na retart uwsgi kreeg ik veel vrije ruimte! - Fabio Montefuscolo
Ik had 40G aan logboeken die in limbo zitten en lsof + L1 gaf me de röntgenvisie om te zien wat er gebeurde ;-) Ik hoefde alleen maar de service opnieuw op te starten. - PJ Brunet


5% (standaard) van het bestandssysteem is gereserveerd voor gevallen waarin het bestandssysteem volraakt om ernstige problemen te voorkomen. Je bestandssysteem is vol. Er is niets catastrofaals aan de hand vanwege de 5% buffer - root is toegestaan ​​om die veiligheidsbuffer te gebruiken en, in jouw opstelling, hebben niet-rootgebruikers geen reden om in dat bestandssysteem te schrijven.

Als je daemons hebt die worden uitgevoerd als een niet-rootgebruiker, maar die bestanden in dat bestandssysteem moeten beheren, zullen de dingen kapot gaan. Een veel voorkomende daemon is dat named. Een andere is ntpd.


42
2017-09-24 21:46



Op de kwestie van WAAROM je schijf is vol, 7G is echt niet zoveel ruimte. Je lijkt ook te hebben alles gedumpt onder één partitie / bestandssysteem (/). Dit wordt over het algemeen als een Slecht ding beschouwd (want als er iets misgaat / vult en de wereld eindigt), maar Linux-distributies blijven het nog steeds doen omdat het "eenvoudiger" is. Ik zou beginnen door naar binnen te kijken /var (Esp. /var/log) voor enorme logbestanden. du -hs / (als root) zal je helpen de grootste mappen te vinden en je eventueel wijzen op wat opgeruimd moet worden. - voretaq7


Misschien heb je geen inodes meer. Controleer inode gebruik met deze opdracht:

df -i

33
2017-09-24 21:48





De meeste Linux-bestandssystemen reserveren 5% ruimte voor alleen de root-gebruiker.

Je kunt dit zien met bijvoorbeeld

dumpe2fs /dev/sda1 | grep -i reserved

U kunt de gereserveerde hoeveelheid wijzigen met:

tune2fs -m 0 /dev/sda1

In de meeste gevallen zal de server prima blijven werken - ervan uitgaande dat alle processen als 'root' worden uitgevoerd.


15
2017-09-25 08:39





Ik had dit probleem en was verbijsterd door het feit dat het verwijderen van verschillende grote bestanden de situatie niet verbeterde (wist niet van de 5% -buffer) toch naar aanleiding van enkele aanwijzingen hier

Van de root liep de grootste directories door, onthuld door herhaaldelijk te doen:

du -sh */ 

totdat ik een directory voor webserver logbestanden kwam die enkele absoluut enorme logs had

waarmee ik afgekapt ben

:>lighttpd.error.log

plotseling df -h was terug tot 48% gebruikt!


8
2017-11-26 13:25



Dat zou echt moeten eindigen met "... dan zet ik logrotatie op". - hayalci
hayalci: vond dat de logrotatie naar de verkeerde map wees. - zzapper


Naast de reeds gesuggereerde oorzaken, zou het in sommige gevallen ook kunnen volgen:

  • een andere schijf is "over" de bestaande map die vol met gegevens is gemonteerd
  • du berekent de bestede grootte van de gemounte schijf en df toont echt besteed
  • oplossing: (indien mogelijk) unmount alle niet-root-schijven en controleer de grootte met du -md 1 nog een keer. Fix situatie door te bewegen verborgen map naar een andere plaats of mount op een andere plaats.

8
2017-10-23 18:41



hoe vind je andere mountpunten dan df? - Hogan
@Hogan: zou het kunnen helpen om "mount" of "cat / etc / fstab" te gebruiken? - Robert Lujo


df -h rondt de waarden af. Zelfs de percentages zijn afgerond. Laat de -hen je ziet fijnere korrelverschillen.

Oh. En ext3 en derivaten reserveren een percentage (standaard 5%) voor het bestandssysteem voor precies deze problematische constellatie. Als uw rootbestandssysteem echt vol is (0 byte overgebleven), kunt u het systeem niet opstarten. Dus het gereserveerde gedeelte voorkomt dit.


5
2017-09-24 20:40



Kan ook zijn dat hij geen vrije inodes meer heeft. Voer 'df -i' uit om inodes te gebruiken. - Andrew Case
Hij gaf geen informatie dat de schijf is vol. Hij alleen denkt dat de schijf vol is. 100% gebruikte ruimte zonder fouten is alleen "virtueel vol". - mailq


controleer de / lost + found, ik had een systeem (centos 7) en een deel van het bestand in de / lost + found at alle ruimte op


0
2017-11-23 22:31





Als je partitie btrfs is, kan er een subvolume zijn dat ruimte in beslag neemt. Een btrfs-bestandssysteem kan vele subvolumes hebben, waarvan er slechts één is gemount. Je kunt gebruiken btrfs subvolume list <dir> om alle subvolumes en btrfs subvolume delete <dir>/<subvolume> om er een te verwijderen. Zorg ervoor dat je degene die standaard is gemount niet verwijdert.


0
2018-05-16 19:25





Ik heb een grote update van verschillende bibliotheken gemaakt en er waren veel onnodige bibliotheken en tijdelijke bestanden, dus ik bevrijde ruimte in de map "/" met behulp van:

apt-get install -f
sudo apt-get clean

En maak je vuilnis leeg


0
2018-02-06 09:14



Dit is een redelijk algemeen advies over het verminderen van het schijfgebruik, maar het gaat niet over de vraag waarom df zegt dat de schijf vol is als dat niet het geval is. - Andrew Schulman