Von ext4 verwendeter Speicherplatz (keine Option -m, keine gelöschten Dateien)

Question

Ich bin etwas verwirrt über die Art und Weise, wie ext4 den belegten Speicherplatz meldet. Bei einer neuen Debian-Wheezy-Installation (Test) wurde mir mit einer 60 GB SSD im Vergleich zu konstant etwa 1 GB zusätzlicher Speicherplatz belegt du. Dann habe ich den Computer über das Netzwerk gebootet und die SSD eingebunden. Das über das Netzwerk gebootete Betriebssystem (Debian Squeeze) zeigt nur 180 MB zusätzlichen Speicherplatz auf der SSD an. Das Journal ist 128 MB groß, also ist darüber hinaus nicht mehr viel Speicherplatz vorhanden.

Was ist der von gemeldete zusätzlich genutzte Speicherplatz df, wenn es sich nicht um für Root- oder gelöschte Dateien reservierten Speicherplatz handelt? Die Verwendung von Google führt meist zu den üblichen Ursachen, die ich ausgeschlossen habe. Und warum unterscheidet sich diese Menge auf demselben Dateisystem, wenn es auf verschiedenen Betriebssystemen gemountet ist? Ich habe dies durch Neuinstallation getestet und der zusätzliche Verbrauch betrug bei der Wheezy-Installation wieder ~1 GB und 180 MB, als ich per Netzwerk gebootet und diese SSD gemountet habe.

Bei XFS und btrfs scheint der zusätzlich gemeldete Verbrauch vernachlässigbar. Mir ist klar, dass das Dateisystem einen gewissen Overhead benötigt, aber es ist unpraktisch, wenn dieser Overhead mit dem tatsächlichen Verbrauch vermischt wird.

Hier sind einige detaillierte Ausgaben.

df

$ df -m on wheezy
Filesystem              1M-blocks  Used Available Use% Mounted on
rootfs                      57132  1567     52703   3% /
udev                         7899     0      7899   0% /dev
tmpfs                        1581     1      1581   1% /run
/dev/mapper/ssd-kvmhost     57132  1567     52703   3% /
tmpfs                           5     0         5   0% /run/lock
tmpfs                        3162     0      3162   0% /tmp
tmpfs                        3162     0      3162   0% /run/shm

du

$ du -sm /
592     /

tune2fszeigt eine Inode-Anzahl von 3670016 und eine Größe von 256, was tatsächlich fast den gesamten belegten Speicherplatz erklärt. Ich verstehe nur nicht, warum dies nicht von der Größe abgezogen wird, da die Inodes statisch reserviert sind. Es als Speicherplatz und dann immer als belegt zu zählen, ergibt nicht viel Sinn.

Hier ist die Ausgabe für genau dasselbe Dateisystem aus dem über das Netzwerk gebooteten Debian Squeeze:

aufs                      7905        46      7859   1% /
tmpfs                     7905         0      7905   0% /lib/init/rw
udev                      7900         1      7900   1% /dev
tmpfs                     7905         1      7905   1% /dev/shm
172.17.172.127:/storage/private/tftp/debian-live-6.0.3-amd64-lxde-desktop
                         24737     17448      7289  71% /live/image
tmpfs                     7905        46      7859   1% /live/cow
tmpfs                     7905         0      7905   0% /live
tmpfs                     7905         1      7905   1% /tmp
/dev/mapper/ssd-kvmhost
                         56337       772     52703   2% /mnt

Und nur zur Bestätigung, du -sm / auf dem über das Netzwerk gebooteten Betriebssystem:

592     /

Vielleicht zählt der ältere Kernel den statisch reservierten Inode-Speicherplatz klugerweise nicht als nutzbar und muss ihn daher nicht als genutzt anzeigen? Der Unterschied beträgt sowohl bei der Größe als auch bei der Nutzung 795 MB, fast der gesamte für die Inodes benötigte Speicherplatz. Was sind dann die 180 MB? Wenn das auch statisch ist, wäre es dann nicht optimal, das auch von der Größe abzuziehen? Dann dfkönnte man tatsächlich die tatsächliche Nutzung anzeigen, wie es andere Dateisysteme zu tun scheinen.

So wie ich das sehe, wenn mein Dateisystem eine statische Menge an Overhead benötigt, dann bietet es einfach weniger nutzbaren Speicherplatz als einige andere Dateisysteme für die gleiche Menge an absolutem Speicherplatz. Sollte df das nicht widerspiegeln und auch zeigen, wie viel von demNutzflächeIch habe benutzt?

Answer 1

ext[234] reserviert standardmäßig 8192 Inodes pro 128-MB-Blockgruppe, was 2 MB pro Gruppe in Anspruch nimmt, was bei einem 60-GB-Dateisystem fast 1 GB ausmacht. Es sollte keinen Unterschied geben, wenn Sie das Laufwerk in einem anderen System mounten. Es sieht so aus, als hätten sie die Art und Weise geändert, wie der Kernel den verwendeten Speicherplatz zwischen Wheezy und Squeeze meldet, obwohl ich noch kein Commit gefunden habe, das darauf hinweist, dass dies absichtlich getan wurde.

Answer 2

Ihre Frage ließe sich leichter beantworten, wenn Sie die Ausgabe von df und du angeben würden.

Aber es klingt sehr nach df sagt, ich habe 20 GB mehr Speicherplatz genutzt als du. Warum?

Grundsätzlich verwendet Ihr Dateisystem einen Teil der Festplatte für seine eigenen Metadaten, also nicht die Dateien selbst, sondern um die Dateien, ihre Namen, ihre Berechtigungen, ihren Speicherort auf der Festplatte usw. zu verfolgen.

Wie in der Antwort, auf die ich oben verlinkt habe, steht, tune2fs -l <device name>werden Ihnen beim Ausführen weitere Informationen angezeigt. Insbesondere sollte inode countx in der Nähe der Differenz zwischen und liegen .inode sizedfdu

Basierend auf der vorherigen Antwort verwendet die Root-Partition meines Systems etwa 1,77 % der Festplatte für Inodes. 60 GB * 0,0177 ~ = 1 GB.

Ich vermute, dass die Zahl von 180 MB falsch ist, kann aber ohne weitere Details, z. B. die Ausgabe auf Ihrem über das Netzwerk gebooteten System, nicht sicher sein mount. Vielleicht liegt es beispielsweise an derminixdf/bsddfEinhängeoption.