System frisch und nach 3 tagen HDD voll

[DaCrow]

hiho!
ich habe letzte woche auf meinem server eine frische debian installation auf einer 8GB partition durchgeführt. da ich das system möglichst klein halten wollte, habe ich die netz-installation ausgeführt und nachdem das basis-system installiert war, keine weitere software installiert.
erst später habe ich dann ganz explizit das installiert, was ich wirklich brauchte. dazu gehörte u.a. der mlDonkey.

heute versuchte ich mldonkey mal wieder zu starten, aber das programm wollte nicht so wie ich. es beendete sich sofort wieder und es wurde auch keine mlnet.log erstellt.

ich hab mich gewundert, was da los ist und stellte nun mittels df -h fest, dass meine ganze 8GB partition mittlerweile voll ist!!! - doch wovon???
es sind nur noch murkelige 512KB frei. das wars. kein wunder, das mlnet nicht starten kann....das muss ja in den home-verzeichnissen zb loggen etc...

ich kann mir einfach nicht vorstellen, was auf einmal meine ganze festplatte belegt...
meine frage nun: wie würdet ihr vorgehen? welche dateien in einem linux-system können recht schnell recht groß werden (wie zb log dateien)? und wo befinden sich diese im system?
gibt es ein programm, was mir die dateien der gesamten partition der größe nach anzeigt, so dass ich entscheiden kann, welche der größten ich löschen kann?
gibt es sonst irgendeine möglichkeit, rauszufinden, was in meinem system die platte vollmüllt??

greetz

[kreol]

find / -size +500Mzeigt Dir alle Dateien > 500M an... Führe es am besten als root aus, sonst werden manche Dateien mangels Leserecht nicht angezeigt.
Verdächtig ist in erster Linie das Verzeichnis /var/log/ und natürlich /home. Da würde ich als erstes nach großen Dateien suchen, oder halt, wie oben, im gesamten Verzeichnisbaum.
Mit
du -hs /verzeichnisnamekannst Du dir die Größe von Verzeichnissen anzeigen lassen. Kann auch nützlich sein. Schau Dir auf der manpage von du auch mal die Option -c an. Ist nützlich für Dateigrößen.


Kreol

[DaCrow]

hmmmm... ich hab jetzt mal zwei alte kernel-sources gelöscht, so wurden 72MB frei und schwupps - mldonkey startet wieder....


seltsam.... du -hs /* gibt folgendes aus:


server:/home/dacrow# du -hs /*
3,1M /bin
16M /boot
0 /cdrom
96K /dev
5,7M /etc
69M /home
4,0K /initrd
0 /initrd.img.old
84M /lib
48K /lost+found
22G /media
4,0K /mnt
4,0K /opt
258M /proc
7,1M /root
3,0M /sbin
4,0K /srv
0 /sys
12K /tmp
1,1G /usr
116M /var
0 /vmlinuz
0 /vmlinuz.old
server:/home/dacrow#

unter /media sind noch zwei andere festplatten eingebunden, da sind die 22GB berechtigt... aber die restlichen angaben machen doch nicht meine 8GB root-partition voll....
dafür gibt mir df -h folgendes an:


server:/home/dacrow# df -h
Dateisystem Gröe Benut Verf Ben% Eingeh
/dev/hdc1 7,7G 7,3G 55M 100% /
tmpfs 126M 0 126M 0% /dev/shm
/dev/hdc3 29G 16G 12G 58% /media/hdc3
server:/home/dacrow#

/dev/hdc1 ist meine root partition. grad eben hab ich da erst die 72mb frei gemacht, nun sinds nur noch 55mb und mldonkey läuft erst seit 5min...
also, mir scheint es so, als ob das irgendwie mit dem mldonkey zusammenhängt...

außerdem versteh ich nicht, warum df -h und du -hs so unterschiedliche ergebnisse liefern...

[Tuxx]

Ich hab mir da so ne Kleinigkeit in die ~/.bashrc geschrieben:


alias ducks='du -chks * |sort -rn |head -11'

Zeigt dir mit Aufruf von "ducks" an wo die fetten Enten sitzen. :D

Nur so am Rande.
Wo dein Problem liegt kann ich in deinem Tree beim besten Willen nicht erkennen.

[kreol]

Laß mal den * bei du weg. Hier sieht es so aus:
P800:/ # du -hs /
8,5G /

P800:/ # du -hs /*
6,5M /bin
6,3M /boot
2,8G /data
120K /dev
22M /etc
1,7G /home
89M /lib
577M /opt
513M /proc
900K /root
11M /sbin
545M /shared
2,5M /srv
0 /subdomain
0 /sys
16K /tmp
2,2G /usr
154M /varAlso die einzelnen Verzeichnisse ergeben auch keine 8,5GB. Trotzdem:
P800:/ # df
Dateisystem 1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf
/dev/hda8 11317408 3042980 8274428 27% /
/dev/hda9 6176764 1791096 4385668 29% /home
/dev/hda3 6164932 557280 5607652 10% /shared
/dev/hda10 20554504 2884116 17670388 15% /data



Kreol

[Tuxx]

Die Standardsuche nach den üblichen Verdächtigen würde mich erstmal zu:
/tmp
/var/log
/var/spool
~./tmp
führen.

[DaCrow]

merkwürdig... ich finde einfach nicht den übeltäter... alle dateien, die mir angezeigt werden, haben ihre berechtigung, so groß zu sein, wie sie sind und tragen auch nicht zu diesem überbelegen meiner hdd bei..

@Tuxx:also der "du -chks * |sort -rn |head -11" war schonmal ein sehr guter tip, den muss ich mir unbedingt auch in die .bashrc schreiben. leider hilft er mir bei meinem problem nicht weiter, da die ausgabe wie folgt aussieht:


server:/# du -chks * |sort -rn |head -11
17453685 insgesamt
15778084 media
1111548 usr
262385 proc
118200 var
85188 lib
63460 home
15524 boot
7216 root
5752 etc
3132 bin
server:/#
ich habe in /media im vergleich zu meinen posts von gestern ein bissl was gelöscht, daher sind dort nur noch 15Gb gelistet. aber das dürfte ja nicht das problem sein, da sich in /media andere festplatten/-partitionen befinden.
alle weiteren verzeichnisse, die dort gelistet sind, ergeben zusammen auch nicht die 8Gb meiner root-partition.
der du-befehl berücksichtigt ja auch die größe der unterverzeichnisse, oder?? daran wirds wohl auch nicht liegen...
in den verzeichnissen
/tmp
/var/log
/var/spool
~./tmp
hab ich auch nix so großes liegen, als dass es den rest meiner 8Gb partition belegen würde...

@kreol: naja, bei dir sind anscheinend ja /home, /shared und /data auf extra partitionen ausgelagert, während /dev/hda8 den rest deiner root-partition darstellt. rechne ich die einzelnen größen der verzeichnisse von "P800:/ # du -hs /*" zusammen (/home,/shared und /data nicht mitgerechnet), so komme ich auf ca ~3.5Gb. da bei dir df folgende ausgabe macht
P800:/ # df
Dateisystem 1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf
/dev/hda8 11317408 3042980 8274428 27% /
kommt das doch so ungefähr hin:
~3.5Gb <-> 3042980

bei mir klappt diese rechnung aber ganz und garnicht...

das einzige was mir jetzt noch einfällt, woran es liegen könnte:
rechnet der du-befehl bei seinen größenangaben auch dateien mit ein, die versteckt sind?? vielleicht hat mldonkey ja eine versteckte, riesengroße datei angelegt, die ich deshalb mittels "du" nicht finden kann?!

[choener]

umount 'e mal media/... und schaue nach, ob du da irgendwas geparkt hast.

[kreol]

DaCrow: Ich wollte auch nur verdeutlichen, daß sich die Ausgaben von "du -hs /*" und "du -hs /" unterscheiden ;)


Kreol

[mianos]

hey kreol, ich hab mal ganz schwer den verdacht das mldonkey die temp files bei dir auf der root-partition schreibt. ~/.mldonke/...?

achja, bei amule und ich meine auch bei mldonkey is das mit den temp-files so:

du willst eine 2gb datei saugen.
sobald er anfängt zu saugen schreibt er das tempfile und alles was noch nicht geladen wurde wird vollgeschrieben. sprich, du hast zwar bloß 2mb gesaugt aber es sind, als speicherreservierung gedacht, 2gb belegt ;)

[kreol]

hey kreol, ich hab mal ganz schwer den verdacht das mldonkey die temp files bei dir auf der root-partition schreibt. ~/.mldonke/...?Aber ich 'abe gar kein mldonkey, signora... :p
Meinst Du nicht DaCrow? ;)


Kreol

[choener]

du willst eine 2gb datei saugen.
sobald er anfängt zu saugen schreibt er das tempfile und alles was noch nicht geladen wurde wird vollgeschrieben. sprich, du hast zwar bloß 2mb gesaugt aber es sind, als speicherreservierung gedacht, 2gb belegt ;)

Dann sollte man dringenst den Client wechseln. Normalerweise sollte ls zwar 2gig anzeigen, du -h fname aber den tatsaechlich belegten Speicher angeben. Das kann sich unterscheiden, weil man Speicherplatz im filesys auch "virtuell" reservieren kann. (um mal einfach zu bleiben)

[mianos]

oh wusst ich nicht - wenn ich jetzt 30 gig an downloads anschmeisse (amule) dann zeigt df -h das auch an ...:confused:

@kreol : ups ;)

[choener]

oh wusst ich nicht - wenn ich jetzt 30 gig an downloads anschmeisse (amule) dann zeigt df -h das auch an ...:confused:

Ohne das jetzt grossartig weiterzuführne, weil es ja doch etwas offtopic ist... sind denn unter preferences/files Optionen für "reduce fragmentation" an?