问题描述
\\n
df
\\n
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/vda1 30830588 22454332 6787120 77% /
none 4 0 4 0% /sys/fs/cgroup
udev 1014124 4 1014120 1% /dev
tmpfs 204996 336 204660 1% /run
none 5120 0 5120 0% /run/lock
none 1024976 0 1024976 0% /run/shm
none 102400 0 102400 0% /run/user
那个77%昨天才60%，几天后就会填满100%。
我已经监视文件大小有一段时间了：
sudo du -sch /*
9.6M /bin
65M /boot
224K /build
4.0K /dev
6.5M /etc
111M /home
0 /initrd.img
0 /initrd.img.old
483M /lib
4.0K /lib64
16K /lost+found
8.0K /media
4.0K /mnt
4.0K /opt
du: cannot access ‘/proc/21705/task/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/task/21705/fdinfo/4’: No such file or directory
du: cannot access ‘/proc/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/fdinfo/4’: No such file or directory
0 /proc
21M /root
336K /run
12M /sbin
8.0K /srv
4.1G /swapfile
0 /sys
4.0K /tmp
1.1G /usr
7.4G /var
0 /vmlinuz
0 /vmlinuz.old
14G total
它每天都给我(或多或少)相同的数字。总共 14G 还不到磁盘大小的一半。其余的都去哪儿了？
我对 Linux 的了解还不是很深入。
是否有可能文件不显示在这里？是否有可能以其他方式分配空间？
最佳方案
如果磁盘空间出现不可见的增长，那么罪魁祸首可能是已删除的文件。在 Windows 中，如果您尝试删除某个程序打开的文件，则会收到错误。在 Linux 中，该文件将被标记为已删除，但数据将保留，直到应用程序释放。在某些情况下，这可以用作 a neat way to clean up after yourself – 应用程序崩溃不会阻止临时文件被清除。
查看已删除的 still-used 文件：
lsof -b 2>/dev/null | grep deleted
您可能删除了大量文件 – 这本身不是问题。但单个删除的文件变大才是问题。
重新启动应该可以解决这个问题，但是如果您不想重新启动，请检查所涉及的应用程序(lsof 输出中的第一列)并重新启动或关闭看起来合理的应用程序。
如果你看到类似这样的内容：
zsh 1724 muru txt REG 8,17 771448 1591515 /usr/bin/zsh (deleted)
如果应用程序和删除的文件相同，则可能意味着应用程序已升级。您可以忽略这些占用大量磁盘空间的因素(但您仍应重新启动程序以使 bug-fixes 生效)。
/dev/shm 中的文件是共享内存对象，不会占用太多磁盘空间(我认为最多占用一个 inode 号)。它们也可以安全地忽略。名为 vteXXXXXX 的文件是来自基于 VTE 的终端仿真器(如 GNOME Terminal、Terminator 等)的日志文件。如果您打开了一个终端窗口，其中输出了大量(我的意思是大量)内容，这些文件可能会很大。
次佳方案
补充一下 muru 的精彩回答：
-
df 显示磁盘大小，
-
du 显示文件内容的总大小。
也许您使用 du 看不到的是许多小文件的出现……(查看 df -i 的最后一列，看看 inode 的数量(即文件的数量)是否也随着时间的推移而增加了很多)
如果你碰巧有 1’000’000(100 万)个 1 字节的小文件，du 会将其算作总共 1’000’000 字节，也就是 1Mb(……纯粹主义者，请不要畏缩)
但在磁盘上，每个文件由两部分组成：
-
1 个 inode(指向文件的数据)，该 inode 本身可以是 16kb(!)，
-
并且每个文件的数据(=文件的内容)都放在磁盘块上，并且这些块不能包含多个文件的数据(通常……)，因此您的 1 字节数据将占用至少 1 个块
因此，一百万个 1 字节文件将占用 1'000'000'000 * size_of_a_block 的总数据空间，加上 1'000'000'000 * size_of_an_inode 的 inode 大小……对于一百万个 “1-byte” 文件，这将占用数 GB 的磁盘使用量。
如果您有 1024 字节的块和另外 256 字节的 inode 大小，则 du 会将 1’000’000 文件报告为大约 1Mb，但在磁盘上将计为大约 1.25Gb(如 df 所示)！(或者甚至是 2Gb，如果每个 inode 也必须位于 1 个专用磁盘块上…我不知道是否是这种情况)