Festplattenplatz Linux-Server

chr0n0s

Stammuser
Hallo,

ich habe ein seltsames Phänomen und wollte mal wissen, ob jemand evtl. weiß woran das liegen könnte.

Mit
Code:
df -h
wird mit angezeigt, dass meine Festplatte gerade 64G von insgesamt 95G Speicherplatz in Benutzung hat.

Seltsamerweise habe ich mal mit
Code:
du -h --max-depth=1 /
meine Verzeichnisse überprüft und festgestellt, dass die Verzeichnisse insgesamt 6,3G an Speicherplatz verbrauchen.

Wie kann dieser massive unterschied entstehen?

Es handelt sich um eine VM mit Debian 6, welcher als Webserver- und Datenbank-Server läuft. Die Datenbank selbst kann es ja nicht sein, da diese im Verzeichnis
Code:
/var/lib/mysql/
seine Daten ablegt und dieses gerade mal 2,6G groß ist.

Any Idea? Oder was kann ich ggf. noch prüfen? Stehe gerade auf dem Schlauch.

Danke.
 

bitmuncher

Senior-Nerd
Welches Dateisystem wird verwendet? Sind ggf. irgendwelche Snapshots vorhanden, die Platz fressen? Wie viel Platz wird vom Dateisystem für Journaling etc. reserviert?
 

chr0n0s

Stammuser
Welches Dateisystem wird verwendet?

ext3

Sind ggf. irgendwelche Snapshots vorhanden, die Platz fressen?

Edit: Lt. VMWare-Server liegt der Snapshot-Speicherplatz bei 0.0 GB

Wie viel Platz wird vom Dateisystem für Journaling etc. reserviert?

Ausgabe cat /etc/mke2fs.conf
Code:
blocksize = 4096
inode_size = 256
inode_ratio = 16384

largefile = { inode_ratio = 1048576 }

Glaube das war was Du wissen wolltest?!
 
Zuletzt bearbeitet:

bitmuncher

Senior-Nerd
Multiplizier mal bitte die von 'tune2fs -l <device>' ausgegebenen Werte für "inode count" und "inode size". Damit hast du einen echten Wert für den reservierten Platz.

Beispiel:
Code:
root@ktsnet1:/home/bitmuncher# tune2fs -l /dev/md1  |grep Inode
Inode count:              24109056
Inodes per group:         8192
Inode blocks per group:   512
Inode size:	          256
root@ktsnet1:/home/bitmuncher# bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
24109056*256
6171918336
Es sind also in diesem Beispiel 6171918336 Bytes für die Inodes reserviert.
 

chr0n0s

Stammuser
Also,

Ausgabe 'tune2fs':
Code:
root@server:~# tune2fs -l /dev/sda1 | grep Inode
Inode count:                 6291456
Inodes per group:           8192
Inode blocks per group:   512
Inode size:                    256

Berechnung:
Code:
6291456*256
1610612736

Mmh, sieht weniger aus als bei Dir :)

Festgestellt habe ich nun, dass wieder 1G mehr in 'use' ist. Ebenfalls musste ich trotz 'VMWare Tools' den Speicherplatz mit GParted erweitern, da die Zuordnung von Speicherplatz im System nicht erkannt wurde.

Bin eigtl. fest der Meinung, dass meine Debian-/CentOS-Systeme bei mir zu Hause auf einem 'XenServer' damit anders umgehen.

Könnte es auch daran liegen, dass die Debian 6 Maschine mit einem Debian 5 VMWare-Template erstellt wurde und die daraus resultierende 'innere' Konfiguration zw. VMWare und dem eigentlich installierten Debian 6 nicht optimal funktioniert und dort was faul ist?
 

Dresko

Stammuser
Festgestellt habe ich nun, dass wieder 1G mehr in 'use' ist. Ebenfalls musste ich trotz 'VMWare Tools' den Speicherplatz mit GParted erweitern, da die Zuordnung von Speicherplatz im System nicht erkannt wurde.

Bin eigtl. fest der Meinung, dass meine Debian-/CentOS-Systeme bei mir zu Hause auf einem 'XenServer' damit anders umgehen.

Könnte es auch daran liegen, dass die Debian 6 Maschine mit einem Debian 5 VMWare-Template erstellt wurde und die daraus resultierende 'innere' Konfiguration zw. VMWare und dem eigentlich installierten Debian 6 nicht optimal funktioniert und dort was faul ist?

Keine Ahnung wie das bei XEN aussieht, aber bei VMWare virtualisierten Gästen kommt es häufiger mal vor, dass er im Livebetrieb eine Vergrößerung der Platte oder eine neue Platte nicht erkennt und man erst rebooten muss.

Es gibt aber noch einen kleinen Trick:
Code:
echo "- - -" > /sys/class/scsi_host/host0/scan
fdisk -l

Generell würde ich dir aber für Linuxgäste empfehlen LVM zu verwenden. Wir arbeiten in der Regel mit mehreren VMDKs, LVM und ext4 und damit können wir im Livebetrieb Platten vergrößern oder verkleinern.

Wir fügen einem Gast im Betrieb eine neue VMDK hinzu, weisen die Platte einer volume group zu und können dann das entsprechende logical volume erweitern (mit lvextend). Da wir ext4 verwenden, können wir letztendlich das Dateisystem mit "resize2fs" erweitern. Auf dem umgekehrten Weg kann ich dem Gast auch diesen neuen Speicherplatz wieder wegnehmen. Hört sich umständlich an, geht aber flott von der Hand und ist meistens in wenigen Minuten erledigt.
 

chr0n0s

Stammuser
Danke, Dresko.

Werde dies bei meinem Einsatz der Linux-VMs berücksichtigen.

Leider behebt das nicht mein Grundproblem. :(

Es kann ja nicht sein, dass ich immer mal den Speicherplatz erweitern muss, bei einer Linux Büchse. Der hat jetzt >100GB an virtueller Festplatte, was ich für einen Linux Guest wesentlich zu hoch empfinde.
 
Oben