ext4: Wo ist mein freier Speicherplatz geblieben?

Ich habe gerade meine Mageia 2 64-Bit-VM auf Mageia 3 aktualisiert, und jetzt ist mein freier Speicherplatz auf der virtuellen Festplatte fast gleich Null, obwohl weniger als 100% des Speicherplatzes verwendet werden.

Ich bin kein Experte für ext4-Dateisysteme, aber ich habe alle relevanten Informationen extrahiert, die mir unten einfallen:

Ausgabe des df -h /Befehls (:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        11G  9.9G     0 100% /

Nur für den Fall, gleiche Ausgabe ohne die -hOption:

Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda1       10645080 10353564         0 100% /

Jetzt mit der -iOption:

Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sda1        670K  338K  332K   51% /

Nach meinem Verständnis sollte ich entweder:
-11G - 9,9G = 1,1G freien Speicherplatz geben oder nehmen, bis zu einer Fehlergrenze von 0,1G, oder
-11G - 9,9G - 0,05 * 11G = 0,55G (um reservierte Blöcke zu nehmen Prozentsatz berücksichtigt (5% in meinem Fall - Standardverteilungsoption)

Ich kann nicht einmal eine Datei erstellen.

Außerdem habe ich zwischen 300 und 500 MB Dateien gelöscht, seit ich zum ersten Mal auf dieses Problem "Kein freier Speicherplatz" gestoßen bin, aber die Standbilder für freien Speicherplatz zeigen immer noch 0 an, obwohl mir seitdem das Erstellen von Dateien verweigert wurde (als Root angemeldet)! Ich habe das System auch mehrmals neu gestartet, um gelöschten Dateien Rechnung zu tragen, die möglicherweise noch geöffnet waren, aber keine Änderung des gemeldeten freien Speicherplatzes erhalten haben. Schließlich betrug die Betriebszeit seit dem ersten Auftreten des Problems höchstens 12 Stunden und du -h /var/logergibt 38 Millionen, sodass hier kein Wahnsinn herrscht.

Die ersten dumpe2fsAusgabezeilen geben Folgendes an:

dumpe2fs 1.42.7 (21-Jan-2013)
Filesystem volume name:   <none>
Last mounted on:          /sysroot
Filesystem UUID:          45b03008-87fa-4684-a98a-bd5177e2b475
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              685440
Block count:              2737066
Reserved block count:     136853
Free blocks:              88348
Free inodes:              339326
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      668
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8160
Inode blocks per group:   510
Flex block group size:    16
Filesystem created:       Mon Aug 20 12:34:41 2012
Last mount time:          Wed May 29 14:29:19 2013
Last write time:          Wed May 29 14:09:03 2013
Mount count:              44
Maximum mount count:      -1
Last checked:             Mon Aug 20 12:34:41 2012
Check interval:           0 (<none>)
Lifetime writes:          66 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       46157
Default directory hash:   half_md4
Directory Hash Seed:      bc061f51-9d12-4851-a428-6fb59984118b
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00015d7c
Journal start:            17427

Schließlich habe ich versucht, mit den reservierten Blockzählungen für alle Fälle zu spielen, und hier ist die Ausgabe:
Befehl:tune2fs -m 0 /dev/sda1 && /usr/bin/df / && tune2fs -m 5 /dev/sda1 && /usr/bin/df /

tune2fs 1.42.7 (21-Jan-2013)
Setting reserved blocks percentage to 0% (0 blocks)
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda1       10645080 10353576    291504  98% /
tune2fs 1.42.7 (21-Jan-2013)
Setting reserved blocks percentage to 5% (136853 blocks)
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda1       10645080 10353576         0 100% /

Wenn ich also den Prozentsatz der reservierten Blöcke auf 0 setze, kann ich ungefähr 285 Millionen wiederherstellen, aber dies entspricht nicht der Worst-Case-Mathematik, einschließlich des Prozentsatzes der reservierten Blöcke, wie ich es verstehe: 11G - 9,9G - 0,05 * 11G = 0,55G. Sagt mir auch nicht, warum ich nach dem Löschen von 300 ~ 500 Millionen Dateien immer noch keine Datei erstellen kann und der freie Speicherplatz als '0' angezeigt wird. Denken Sie daran, dass ich auf jeden Fall als root angemeldet bin, damit ich verstehen kann, dass ich den reservierten Speicherplatz verwenden kann (keine gute Idee, aber nur als Prinzip).

Irgendeine Ahnung, was hier passiert? Kann es (und wie) mit der enormen Menge an Festplattenänderungen sowohl bei der Datengröße als auch beim Erstellen / Löschen von Dateien während des Distributions-Upgrades oder der /usrMigration in Mageia 3 zusammenhängen (kann nicht erkennen, warum, wie /usrauf demselben Dateisystem wie /() keine separate Partition)?

Sie spielen mit der Anzahl der reservierten Blöcke und versuchen, diese über freien Speicherplatz in df mit gerundeten Werten zu steuern .

10645080-10645080*0.05=10112826 blocks are available for normal user

und Sie haben 10353576 Blöcke verwendet, daher ist es normal.

Auch dfrundet Werte. Sie haben 10645080 1K-Blöcke und das ist auf 11G gerundet.

Wirklich ist es 10645080/1024/1024 = 10,15 G, nicht 11 G.

Sie können die df -BMGröße in MB überprüfen. Sie wird mit viel weniger Ungenauigkeit gerundet.