0

当我df -h在我的实例中写作时,我得到了这些数据:

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        7.7G     0  7.7G   0% /dev
tmpfs           7.7G     0  7.7G   0% /dev/shm
tmpfs           7.7G  408K  7.7G   1% /run
tmpfs           7.7G     0  7.7G   0% /sys/fs/cgroup
/dev/nvme0n1p1   32G   24G  8.5G  74% /
tmpfs           1.6G     0  1.6G   0% /run/user/1000

但是当我点击时,sudo du -sh /我得到:

11G /

所以在 中df -h/大小为 24G,但在du -sh同一目录中,大小为 11G。我正在尝试在我的实例上获得一些可用空间,但找不到导致该问题的文件。我错过了什么?真的df -h是在提供假数据吗?

4

1 回答 1

2

这个问题经常出现。文件系统在文件系统中分配磁盘块来记录其数据。此数据称为元数据,大多数用户级程序(例如 du)不可见。元数据的示例包括索引节点、磁盘映射、间接块和超级块。

du 命令是不了解文件系统元数据的用户级程序,而 df 查看文件系统磁盘分配映射并了解文件系统元数据。df 获得真实的文件系统统计信息,而 du 只看到部分图片。

运行 du 或 df 命令时使用或可用的磁盘空间不同的原因有很多。

也许最常见的是已删除的文件。已删除的文件可能仍被至少一个进程打开。此类文件的条目会从关联目录中删除,从而使文件无法访问。因此,只计算文件的命令 du 不考虑这些文件,并得出一个较小的值。但是,只要进程仍在使用已删除的文件,相关块尚未在文件系统中释放,因此在内核级别工作的 df 正确地将这些显示为已占用。您可以通过运行以下命令来确定是否是这种情况:

lsof | grep '(deleted)'

解决此问题的方法是重新启动仍然打开这些已删除文件的服务。

第二个最常见的原因是如果您有一个分区或驱动器安装在同名目​​录的顶部。例如,如果您在 / 下有一个名为 backup 的目录,其中包含数据,然后您在该目录顶部安装一个新驱动器并将其标记为 /backup 但它不包含任何数据,那么即使使用 df 命令,使用的空间也会显示du 命令不显示任何文件。

要确定是否有任何文件或目录隐藏在活动挂载点下,您可以尝试使用绑定挂载来挂载 / 文件系统,这将使我能够在其他挂载点下进行检查。请注意,这仅推荐给有经验的系统管理员。

mkdir /tmp/tmpmnt
mount -o bind //tmp/tmpmnt
du /tmp/tmpmnt

在您确认这是问题后,可以通过运行以下命令删除绑定挂载:

umount /tmp/tmpmnt/
rmdir /tmp/tmpmnt

另一个可能的原因可能是文件系统损坏。如果怀疑有这种情况,请确保您有良好的备份,并在方便时卸载文件系统并运行 fsck。

同样,这应该由有经验的系统管理员来完成。

您还可以通过运行检查计算:

strace -e statfs df /

这将为您提供类似于以下内容的输出:

statfs("/", {f_type=XFS_SB_MAGIC, f_bsize=4096, f_blocks=20968699, f_bfree=17420469, 
f_bavail=17420469, f_files=41942464, f_ffree=41509188, f_fsid={val=[64769, 0]}, 
f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/vda1 83874796 14192920 69681876 17% /
+++ exited with 0 +++

注意 f_bfree 和 f_bavail 之间的区别吗?这些是文件系统中的空闲块与非特权用户可用的空闲块。使用的列只是两者之间的计算。

希望这将使您的想法清晰。如果您仍有任何疑问,请告诉我。

于 2021-11-24T15:20:45.353 回答