ext4：私の空きスペースはどこに行きましたか？

Mageia 2 64ビットVMをMageia 3にアップグレードしたところ、仮想ディスクの空き容量はほぼゼロになりましたが、スペース使用量は100％未満です。

私はext4ファイルシステムの専門家ではありませんが、私が考えることができるすべての関連情報を抽出しました。

コマンド出力df -h /(:

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

場合に備えて-hオプションなしで同じ出力が出力されます。

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

これで、次のオプションがあります-i。

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

私の理解によると、
-11G - 9.9G = 1.1Gの空き容量を0.1Gエラーマージンに丸めるか、
-11G - 9.9G - .05 * 11G = 0.55G（予約ブロックを考慮）の割合（私の場合は5％ -デフォルト割り当てオプション）

ファイルを生成することもできません。

また、「空き容量なし」の問題が最初に発生して以来、300〜500 MBのファイルを削除しましたが、空き容量はまだ0として表示されます。それ以来、ファイルを生成する権限が拒否されました（rootとしてログイン）！また、削除後もまだ開いている可能性がある削除されたファイルを説明するためにシステムを何度も再起動しましたが、報告された空き容量に変更はありません。最後に、最初の発行以降の稼働時間は最大12時間、du -h /var/log提供回数は3,800万回なので、ここにログはありません。

出力の最初の行は次のようになりますdumpe2fs。

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

最後に、万が一に備えてブロック数の維持を試してみたところ、次のような結果が出ました
。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% /

明らかに予約されたブロック率を0に設定すると、約285Mを回復できますが、これは私が理解している予約済みブロック率である11G - 9.9G - .05 * 11G =を含む最悪の数式と一致しません。 0.55G。また、300〜500Mのファイルを削除してもファイルを作成できず、空き容量が「0」で表示される理由もわかりませんでした。とにかく、私はrootとしてログインしているので、予約されたスペースが利用可能でなければならないことを知っています（良い考えではありませんが、原則として）。

ここで何が起こっているのか知っていますか？ Mageia 3では、ディスクローのアップグレードまたは移行中に発生するデータサイズやファイルの作成/削除の大規模なディスクの変更に関連していますか/usr？/usr/