Tôi vừa nâng cấp VM Mageia 2 64 bit của mình lên Mageia 3, và bây giờ không gian trống trên đĩa ảo của tôi gần như không, mặc dù ít hơn 100% dung lượng được sử dụng.
Tôi không phải là chuyên gia về hệ thống tập tin ext4 nhưng tôi đã trích xuất tất cả thông tin liên quan mà tôi có thể nghĩ ra dưới đây:
Đầu ra của df -h /lệnh (:
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 11G 9.9G 0 100% /
Chỉ trong trường hợp, cùng một đầu ra mà không có -htùy chọn:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 10645080 10353564 0 100% /
Bây giờ với -itùy chọn:
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 670K 338K 332K 51% /
Theo hiểu biết của tôi, tôi nên có:
-11G - 9,9G = 1,1G không gian trống cho hoặc lấy làm tròn, biên độ lỗi lên tới .1G hoặc
-11G - 9,9G - .05 * 11G = 0,55G (để lấy các khối dành riêng tỷ lệ phần trăm vào tài khoản (5% trong trường hợp của tôi - tùy chọn phân phối mặc định)
Tôi thậm chí không thể tạo bất kỳ tập tin.
Ngoài ra, tôi đã xóa từ 300-500 MB tệp kể từ lần đầu tiên tôi gặp phải sự cố "không có không gian trống" này nhưng không gian trống vẫn hiển thị 0, mặc dù tôi đã bị từ chối tạo bất kỳ tệp nào kể từ khi (đăng nhập với quyền root)! Tôi cũng đã khởi động lại hệ thống nhiều lần vào tài khoản để xóa các tệp có thể vẫn đang mở trong khi bị xóa, nhưng không có thay đổi trong không gian trống được báo cáo. Cuối cùng, kể từ lần xuất hiện đầu tiên của sự cố, thời gian hoạt động đã kéo dài tối đa 12 giờ và du -h /var/logmang lại 38M nên không có sự điên rồ nào ở đây.
Các dòng dumpe2fsđầu ra đầu tiên cho:
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
Cuối cùng, tôi đã thử chơi đồ chơi với số khối dành riêng chỉ trong trường hợp và đây là đầu ra:
Command: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% /
Vì vậy, rõ ràng, bằng cách đặt tỷ lệ phần trăm khối dành riêng thành 0, tôi có thể phục hồi khoảng 285M nhưng điều này không phù hợp với toán học trường hợp xấu nhất bao gồm tỷ lệ phần trăm khối dành riêng như tôi hiểu: 11G - 9,9G - 0,05 * 11G = 0,55G. Cũng không cho tôi biết lý do tại sao sau khi xóa 300 ~ 500M tệp, tôi vẫn không thể tạo bất kỳ tệp nào và không gian trống hiển thị là '0'. Hãy nhớ rằng trong mọi trường hợp, tôi đã đăng nhập bằng root nên tôi hiểu rằng tôi có thể sử dụng không gian dành riêng (không phải là một ý tưởng hay mà chỉ là một nguyên tắc).
Có manh mối gì đang xảy ra ở đây không? Nó có thể liên quan (và làm thế nào) với số lượng thay đổi lớn về cả kích thước dữ liệu và việc tạo / xóa tệp xảy ra trong quá trình nâng cấp phân phối hay /usrdi chuyển trong Mageia 3 (không thể hiểu tại sao, /usrtrên cùng một hệ thống tệp như /( không phải là một phân vùng riêng)?