![如何诊断和修复丢失的驱动器空间?](https://linux22.com/image/17472/%E5%A6%82%E4%BD%95%E8%AF%8A%E6%96%AD%E5%92%8C%E4%BF%AE%E5%A4%8D%E4%B8%A2%E5%A4%B1%E7%9A%84%E9%A9%B1%E5%8A%A8%E5%99%A8%E7%A9%BA%E9%97%B4%EF%BC%9F.png)
我的 2T 驱动器上有一个小的 ext3/
分区,其可用空间似乎存在差异。我如何确定导致该问题的原因以及如何修复它。
在尝试了我能想到的一切之后,我在启动时强制进行了 fsck,这没有任何影响。
我有其他配置相同的系统,但没有出现这种情况。
# df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 9.7G 8.9G 318M 97% /
# du -shx --max-depth 1 /
5.2G /
# lsof | awk 'BEGIN {t=0} /(deleted)/ {t+=$7} END {print t}'
0
# tune4fs -l /dev/sda1 | grep -E 'state|Free|Reserve|size|Inode'
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem state: clean
Inode count: 2621440
Reserved block count: 131029
Free blocks: 212317
Free inodes: 2487281
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 639
Inodes per group: 32768
Inode blocks per group: 1024
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
Inode size: 128
编辑:
fsck
表示分区有 2% 不连续。
与du
上面的比较(稀疏性):
# du -hxs --apparent-size /
4.9G /
答案1
我想到的一种解释是,您将一些东西隐藏在安装点后面,超出了du
.
在 Linux 上,您可以对根文件系统进行绑定挂载,以便能够在不同的挂载点上查看所有内容。然后仔细查看原始视图中挂载点隐藏的内容。
mkdir /root/root-rebound
mount -o bind / /root/root-rebound
du -sc $(df -P | awk 'NR>2 {print "/root/root-rebound" $6}')
答案2
你有没有看过碎片化的情况?我知道 du 和 df 可以不一致的唯一方法(除了您已经排除的已删除部分)是开销,并且通常来自一堆碎片文件(其中 du 会报告少量,但由于范围的数量这些文件在磁盘上确实很大,如 df 所示)。
该工具可以向您显示 ext3 文件的碎片情况有多严重: