ext4: 내 여유 공간은 어디로 갔나요?

방금 Mageia 2 64비트 VM을 Mageia 3으로 업그레이드했는데 이제 가상 디스크의 여유 공간이 거의 0이 되었지만 공간 사용량은 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-500MB의 파일을 삭제했지만 여유 공간은 여전히 ​​0으로 표시됩니다. 그 이후로 파일을 생성할 수 있는 권한이 거부되었습니다(루트로 로그인)! 또한 삭제 후에도 여전히 열려 있을 수 있는 삭제된 파일을 설명하기 위해 시스템을 여러 번 다시 시작했지만 보고된 여유 공간에는 변화가 없습니다. 마지막으로, 첫 번째 발행 이후 가동 시간은 최대 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"으로 표시되는 이유도 알려주지 않았습니다. 어쨌든 나는 루트로 로그인했기 때문에 예약된 공간을 사용할 수 있어야 한다는 것을 알고 있습니다(좋은 생각은 아니지만 원칙적으로).

여기서 무슨 일이 일어나고 있는지 아시나요? Mageia 3에서 distro 업그레이드 또는 마이그레이션 중에 발생하는 데이터 크기 및 파일 생성/삭제의 대규모 디스크 변경과 관련이 있습니까?( 별도의 파티션이 아닌 동일한 파일 시스템에 있기 /usr때문에 이유를 모르겠습니다 ) )?/usr/