df, du: Völlig unerschiedliche Werte zum belegten Speicherplatz
Auf einem Rechner wird die Größe des belegten Speicherplatzes des Dateisystems auf "/dev/sda1" von "du" und "df" völlig unterschiedlich angezeigt. Nachdem uns das zum ersten Mal aufgefallen ist, habe ich einen Reboot durchgeführt, bei dem die Partition mit "e2fsck" überprüft wurde (erzwungen mit "tune2fs -C 40"). Unmittelbar nach dem Reboot habe ich wie folgt verfahren - leider ist das Problem immer noch da: # df -h / Filesystem Size Used Avail Use% Mounted on /dev/sda1 7.6G 7.0G 216M 98% / # du -shx / 4.2G / # find / -xdev | wc -l 161021 # tune2fs -l /dev/sda1 tune2fs 1.35 (28-Feb-2004) Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: a3f40d6f-51be-448b-bf71-76292772fea0 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal filetype needs_recovery sparse_super Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 1005888 Block count: 2010125 Reserved block count: 100506 Free blocks: 155746 Free inodes: 744793 First block: 0 Block size: 4096 Fragment size: 4096 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16224 Inode blocks per group: 507 Filesystem created: Sat Nov 5 19:00:05 2005 Last mount time: Mon Jan 30 13:28:19 2006 Last write time: Mon Jan 30 13:28:19 2006 Mount count: 1 Maximum mount count: 39 Last checked: Mon Jan 30 13:28:19 2006 Check interval: 15552000 (6 months) Next check after: Sat Jul 29 14:28:19 2006 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode: 8 First orphan inode: 357173 Default directory hash: tea Directory Hash Seed: 59ce6d12-990c-40ad-8268-212ae9bb8291 Journal backup: inode blocks Etwas später habe ich dann einen weiteren Anlauf genommen, leider ohne schlauer zu werden: # lsof -s | grep deleted isam 6354 david 0r REG 8,1 55 357173 /tmp/sh-thd-1138650835 (deleted) vmware-vm 15452 arzt 48u REG 8,1 11948032 357177 /tmp/ram0 (deleted) # df --sync -h / Filesystem Size Used Avail Use% Mounted on /dev/sda1 7.6G 7.0G 212M 98% / # du -shx --apparent-size / 3.9G . Hat jemand eine Idee, was die Ursache des Problems sein könnte? -- Dipl.-Phys. Felix E. Klee Email: fk@linuxburg.de (work), felix.klee@inka.de (home) Tel: +49 721 8307937, Fax: +49 721 8307936 Linuxburg, Goethestr. 15A, 76135 Karlsruhe, Germany
Felix E. Klee schrieb:
Auf einem Rechner wird die Größe des belegten Speicherplatzes des Dateisystems auf "/dev/sda1" von "du" und "df" völlig unterschiedlich angezeigt. [...] # df -h / Filesystem Size Used Avail Use% Mounted on /dev/sda1 7.6G 7.0G 216M 98% / # du -shx / 4.2G / [...] Hat jemand eine Idee, was die Ursache des Problems sein könnte?
Hallo Felix! Bei mir: # df /dev/hda6 -h Dateisystem Größe Benut Verf Ben% Eingehängt auf /dev/hda6 487M 267M 220M 55% /srv # du /srv -sh 242M /srv Und nun? Mach dir keinen Kopf. Guck in die Man-Pages! Da steht: 'du - estimate file space usage'! to estimate heisst schätzen. *g* Ich denke, dass da der Hund begraben liegt. Viele Grüße Martin Ereth
Am Montag, 30. Januar 2006 16:45 schrieb Martin Ereth:
Da steht: 'du - estimate file space usage'! to estimate heisst schätzen. *g*
Habe ich übersehen. Ich frage mich nun, wie der Abschätzmechanismus funktioniert.
Ich denke, dass da der Hund begraben liegt.
Hm, bei dir ist die Differenz ja nicht sonderlich groß. Bei uns kann man aber nicht mehr von Abschätzen sprechen: Der Unterschied zwischen 7.0G und 4.2G ist enorm. -- Dipl.-Phys. Felix E. Klee Email: fk@linuxburg.de (work), felix.klee@inka.de (home) Tel: +49 721 8307937, Fax: +49 721 8307936 Linuxburg, Goethestr. 15A, 76135 Karlsruhe, Germany
Am Montag, 30. Januar 2006 17:04 schrieb Al Bogner:
df -hT
# df -hT / Filesystem Type Size Used Avail Use% Mounted on /dev/sda1 ext3 7.6G 7.0G 205M 98% / Also das gleiche Problem. Ich habe jetzt übrigens mal die Dateien testweise umkopiert auf eine zweite Festplatte, und, siehe da, für die Zielpartition geben "du" und "df" ähnliche Werte an: # df -h /hdsync/scratch/test_backup_von_sda1/ Filesystem Size Used Avail Use% Mounted on /dev/sdb8 162G 4.2G 150G 3% /hdsync/scratch # du -sh /hdsync/scratch/test_backup_von_sda1/ 4.2G /hdsync/scratch/test_backup_von_sda1/ Die bisherigen Ergebnisse legen nahe, dass "df -h /" einen falschen Wert ausgibt. Es steht 3:1 für 4.2GB gegen 7.0GB. ;-) -- Dipl.-Phys. Felix E. Klee Email: fk@linuxburg.de (work), felix.klee@inka.de (home) Tel: +49 721 8307937, Fax: +49 721 8307936 Linuxburg, Goethestr. 15A, 76135 Karlsruhe, Germany
Martin Ereth schrieb:
Felix E. Klee schrieb:
Auf einem Rechner wird die Größe des belegten Speicherplatzes des Dateisystems auf "/dev/sda1" von "du" und "df" völlig unterschiedlich angezeigt. [...] # df -h / Filesystem Size Used Avail Use% Mounted on /dev/sda1 7.6G 7.0G 216M 98% / # du -shx / 4.2G / [...] Hat jemand eine Idee, was die Ursache des Problems sein könnte? Bei mir: # df /dev/hda6 -h Dateisystem Größe Benut Verf Ben% Eingehängt auf /dev/hda6 487M 267M 220M 55% /srv
# du /srv -sh 242M /srv
Mach dir keinen Kopf. Guck in die Man-Pages!
Da steht: 'du - estimate file space usage'! to estimate heisst schätzen. *g*
Ich denke, dass da der Hund begraben liegt.
Hallo Felix! Welche Datentypen trägst du auf dem Gerät herum? Bei mir auf der /srv-Partition liegen nur Text-Dateien. Hast du vielleicht viele Binary-Dateien (z.b.: kompilierte Dateien, exe-files, etc.) auf dem Gerät? Vielleicht zählt da dann was falscht. Dateisystem auf dem Gerät ist vermutlich FAT32. /srv ist bei mir momentan reiserfs (noch 3.x). Vielleicht ist da auch deswegen ein "Verzähler" drinnen. Oder auch wegen der Verteilung aufm system: Eine Datei wird in Blöcken gespeichert, jedenfalls kann nur eine Datei pro Block gespeichert werden, auch wenn noch genügend Platz für eine weitere Datei wäre. W enn dann das eine Programm pro Datei mindestens die Blockgröße nimmt, und das andere die wahre Größe nimmt, kommt auch eine Differenz zustande, die je nach Blöckgröße und Dateisystemgröße variiert. Viele Grüße Martin Ereth
Am Montag, 30. Januar 2006 17:16 schrieb Martin Ereth:
Welche Datentypen trägst du auf dem Gerät herum?
Bei mir auf der /srv-Partition liegen nur Text-Dateien. Hast du vielleicht viele Binary-Dateien (z.b.: kompilierte Dateien, exe-files, etc.) auf dem Gerät?
Vielleicht zählt da dann was falscht.
Ich sehe nicht, wie es dabei zu Problemen kommen kann: Der Kernel macht keinen Unterschied zwischen Binär- und Textdateien.
Dateisystem auf dem Gerät ist vermutlich FAT32.
Es handelt sich hier um eine EXT3-Partitionen.
Oder auch wegen der Verteilung aufm system: Eine Datei wird in Blöcken gespeichert, jedenfalls kann nur eine Datei pro Block gespeichert werden, auch wenn noch genügend Platz für eine weitere Datei wäre. W enn dann das eine Programm pro Datei mindestens die Blockgröße nimmt, und das andere die wahre Größe nimmt, kommt auch eine Differenz zustande, die je nach Blöckgröße und Dateisystemgröße variiert.
Könnte die Ursache sein, nur: Ich habe gerade eben auf eine Backup-Partition gesyncht, mit genau der gleichen Blockgröße: # tune2fs -l /dev/sda1 | grep -i block Block count: 2010125 Reserved block count: 100506 Free blocks: 155746 First block: 0 Block size: 4096 Blocks per group: 32768 Inode blocks per group: 507 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) Journal backup: inode blocks # tune2fs -l /dev/sdb1 | grep -i block Block count: 2010125 Reserved block count: 100506 Free blocks: 882182 First block: 0 Block size: 4096 Blocks per group: 32768 Inode blocks per group: 507 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) Journal backup: inode blocks Auf der Backup-Partition nehmen die gleichen Daten laut "df" deutlich weniger Platz ein: # df -h / Filesystem Size Used Avail Use% Mounted on /dev/sda1 7.6G 7.0G 201M 98% / # df -h /hdsync Filesystem Size Used Avail Use% Mounted on /dev/sdb1 7.6G 4.2G 3.0G 59% /hdsync Irgendwas ist da oberfaul, nur was? Leider ist der Rechner nur per SSH zu erreichen, so dass ich nicht eben mal ein Rescue-System booten und mit den Partitionen in aller Ruhe herumspielen kann. -- Dipl.-Phys. Felix E. Klee Email: fk@linuxburg.de (work), felix.klee@inka.de (home) Tel: +49 721 8307937, Fax: +49 721 8307936 Linuxburg, Goethestr. 15A, 76135 Karlsruhe, Germany
Quoting "Felix E. Klee"
Könnte die Ursache sein, nur: Ich habe gerade eben auf eine Backup-Partition gesyncht, mit genau der gleichen Blockgröße:
Kommt die Differenz evtl. durch sparse files zustande? -- Erhard Schwenk Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de k-itx it-dienstleistungen - http://www.k-itx.net
Am Montag, 30. Januar 2006 18:01 schrieb Erhard Schwenk:
Könnte die Ursache sein, nur: Ich habe gerade eben auf eine Backup-Partition gesyncht, mit genau der gleichen Blockgröße:
Kommt die Differenz evtl. durch sparse files zustande?
Ne, leider auch nicht. Ich hab' ja schon in meinem Ursprungsposting das Ergebnis von "du -shx --apparent-size /" gepostet: Es stimmt im Wesentlichen mit dem von "du -shx /" überein. Sollte es größere Sparse-Files geben, währe das anders. -- Dipl.-Phys. Felix E. Klee Email: fk@linuxburg.de (work), felix.klee@inka.de (home) Tel: +49 721 8307937, Fax: +49 721 8307936 Linuxburg, Goethestr. 15A, 76135 Karlsruhe, Germany
Am 30.01.2006 16:26 schrieb Felix E. Klee:
Auf einem Rechner wird die Größe des belegten Speicherplatzes des Dateisystems auf "/dev/sda1" von "du" und "df" völlig unterschiedlich angezeigt. Nachdem uns das zum ersten Mal aufgefallen ist, habe ich einen Reboot durchgeführt, bei dem die Partition mit "e2fsck" überprüft wurde (erzwungen mit "tune2fs -C 40"). Unmittelbar nach dem Reboot habe ich wie folgt verfahren - leider ist
Soviel ich jetzt auf den OpenSuse-Liste gelesen habe, ist das ein Problem von HAL bzw. Subfs, das da wohl falsche Größen ausspuckt. Darum fliegt das wohl auch in der 10.1 raus. Näheres in der opensuse-factory-Liste, Thread:[opensuse-factory] subfs dropped in 10.1 Beta 2 OJ -- "Ich stoße gern 2.000 Leute vor den Kopf, die nur wegen uns gekommen sind. Genau so will ich sein." (Liam Gallagher, Oasis, Visions 62, S. 21)
Am Montag, 30. Januar 2006 18:20 schrieb Johannes Kastl:
Soviel ich jetzt auf den OpenSuse-Liste gelesen habe, ist das ein Problem von HAL bzw. Subfs, das da wohl falsche Größen ausspuckt.
Aber doch wohl nur bei Wechselmedien? -- Dipl.-Phys. Felix E. Klee Email: fk@linuxburg.de (work), felix.klee@inka.de (home) Tel: +49 721 8307937, Fax: +49 721 8307936 Linuxburg, Goethestr. 15A, 76135 Karlsruhe, Germany
Am 30.01.2006 19:05 schrieb Felix E. Klee:
Aber doch wohl nur bei Wechselmedien?
Da bin ich überfragt, vermute es aber. Oder präziser: Alles was automatisch gemountet wird (bei /dev/sda1 im OP bin ich davon ausgegangen). OJ -- Netzwerksicherheits-Legende Nr. 264: Firewalls schützen vor Viren, Trojanern, Kettenbriefen und Taubenscheiße auf dem Autodach. (Martin Schmitt, de.org.ccc, 30.5.1999)
Johannes Kastl schrieb:
Am 30.01.2006 19:05 schrieb Felix E. Klee:
Aber doch wohl nur bei Wechselmedien?
Da bin ich überfragt, vermute es aber. Oder präziser: Alles was automatisch gemountet wird (bei /dev/sda1 im OP bin ich davon ausgegangen).
Hallo Ihr! Wie ich in vorhergehender Mail schon geschrieben habe, weicht auch bei einer Reiser-3.x Partition, die beim Booten gemountet wird, die Ausgabe von df und dd ab. Einen Fehler aufgrund Transaktionen oder offenen Dateien schließe ich bei mir definitiv aus. Also auch bei Festplatten? Viele Grüße Martin Ereth
Am Montag, 30. Januar 2006 21:47 schrieb Martin Ereth:
(...). Wie ich in vorhergehender Mail schon geschrieben habe, weicht auch bei einer Reiser-3.x Partition, die beim Booten gemountet wird, die Ausgabe von df und dd ab.
dd? Oder eher du? http://namesys.com/faq.html#du Gruß Jan -- God may be subtle, but he isn't plain mean.
Auf einem Rechner wird die Größe des belegten Speicherplatzes des Dateisystems auf "/dev/sda1" von "du" und "df" völlig unterschiedlich angezeigt. Nachdem uns das zum ersten Mal aufgefallen ist, habe ich einen Reboot durchgeführt, bei dem die Partition mit "e2fsck" überprüft wurde (erzwungen mit "tune2fs -C 40"). Unmittelbar nach dem Reboot habe ich wie folgt verfahren - leider ist das Problem immer noch da:
# df -h / Filesystem Size Used Avail Use% Mounted on /dev/sda1 7.6G 7.0G 216M 98% / # du -shx / 4.2G /
Wir hatten mal ähnliche Probleme, als wir versehentlich zwei verschiedene Partitionen auf ein- und dasselbe Verzeichnis gemountet hatten. Und einmal hatte ein fsck Abhilfe gebracht, was hier wohl nicht geholfen hatte... An einen anderen Fall kann ich mich nur noch dunkel erinnern - schade... Aber es war in allen Fällen kein ext2. Thomas Mack TU Braunschweig, Institut für Informationssysteme
* Felix E. Klee wrote on Mon, Jan 30, 2006 at 16:26 +0100:
# df -h / Filesystem Size Used Avail Use% Mounted on /dev/sda1 7.6G 7.0G 216M 98% / # du -shx / 4.2G / # find / -xdev | wc -l 161021
# tune2fs -l /dev/sda1 [...] Block size: 4096
Ja, sollten statisch nur 161021 * ( 4096 / 2 ) / 1024 / 1024 == 314 MB Overhead sein..
Hat jemand eine Idee, was die Ursache des Problems sein könnte?
Eine gemeine Falle ist "hinterm mountpoint versteckt", z.B. sowas wie: $ init S $ umount /usr/ $ dd if=/dev/zero of=/usr/.suchmich. count=$ZIEMLICH_VIEL $ mount /usr dann ist /usr/.suchmich. nicht mehr sichtbar, weil das andere Filesystem ja darüber liegt. df beachtet .suchmich. natürlich, du sieht es aber natürlich nicht. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Am Montag, 30. Januar 2006 21:02 schrieb Steffen Dettmer:
Block size: 4096
Ja, sollten statisch nur 161021 * ( 4096 / 2 ) / 1024 / 1024 == 314 MB Overhead sein..
Warum teils Du 4096 durch zwei?
Eine gemeine Falle ist "hinterm mountpoint versteckt", z.B. sowas wie:
$ init S $ umount /usr/ $ dd if=/dev/zero of=/usr/.suchmich. count=$ZIEMLICH_VIEL $ mount /usr
dann ist /usr/.suchmich. nicht mehr sichtbar, weil das andere Filesystem ja darüber liegt. df beachtet .suchmich. natürlich, du sieht es aber natürlich nicht.
Das könnte in der Tat die Ursache sein. Mit welchem Tool kann man im laufenden Betrieb herausfinden, ob das der Fall ist? Interessant wäre z.B. ein Tool, mit dem man sich die vollständige Liste der Dateien auf "/dev/sda1" anzeigen lassen kann. -- Dipl.-Phys. Felix E. Klee Email: fk@linuxburg.de (work), felix.klee@inka.de (home) Tel: +49 721 8307937, Fax: +49 721 8307936 Linuxburg, Goethestr. 15A, 76135 Karlsruhe, Germany
Am Dienstag, 31. Januar 2006 10:28 schrieb Felix E. Klee:
Eine gemeine Falle ist "hinterm mountpoint versteckt", z.B. sowas wie: [...]
Das könnte in der Tat die Ursache sein. Mit welchem Tool kann man im laufenden Betrieb herausfinden, ob das der Fall ist?
Hab' gerade "debugfs" entdeckt und gleich mal ausprobiert. Es sieht so aus, als ob sich Steffens Vermutung bestätigt hat: $ mount | grep ' /nfsroot' /dev/sda7 on /nfsroot type ext3 (rw,acl,user_xattr) # debugfs /dev/sda1 debugfs 1.35 (28-Feb-2004) debugfs: ls /nfsroot 519169 (12) . 2 (12) .. 519171 (4072) 9.2 -- Dipl.-Phys. Felix E. Klee Email: fk@linuxburg.de (work), felix.klee@inka.de (home) Tel: +49 721 8307937, Fax: +49 721 8307936 Linuxburg, Goethestr. 15A, 76135 Karlsruhe, Germany
Felix E. Klee schrieb:
Das könnte in der Tat die Ursache sein. Mit welchem Tool kann man im laufenden Betrieb herausfinden, ob das der Fall ist? Interessant wäre z.B. ein Tool, mit dem man sich die vollständige Liste der Dateien auf "/dev/sda1" anzeigen lassen kann.
Bei mir ist /home/daten eine separate Partition ls /home/daten --> Dateien werden angezeigt # Bindet das Wurzelverzeichnis an /mnt/test mount --bind / /mnt/test/ ls /mnt/test/home/daten --> Nix wird angezeigt, da das Verz. /home/daten an sich leer ist. Wenn was drin ist, kannst du es löschen / verschieben. Zum Schluss umount /mnt/test Grüße, Sven
* Felix E. Klee wrote on Tue, Jan 31, 2006 at 10:28 +0100:
Das könnte in der Tat die Ursache sein. Mit welchem Tool kann man im laufenden Betrieb herausfinden, ob das der Fall ist?
Orginalpartition nochmal woanders hin r/o mounten? oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
participants (9)
-
Al Bogner -
Erhard Schwenk -
Felix E. Klee -
Jan Ritzerfeld -
Johannes Kastl -
Martin Ereth -
Steffen Dettmer -
Sven Niese -
Thomas Mack