磁盘慢慢填满，但没有明显的文件大小变化

Question 1

如果磁盘空间出现不可见的增长，那么罪魁祸首可能是已删除的文件。在 Windows 中，如果您尝试删除某个程序打开的文件，则会收到错误。在 Linux 中，该文件将被标记为已删除，但数据将保留，直到应用程序释放。在某些情况下，这可以用作一个干净整洁的方法- 应用程序崩溃不会阻止清理临时文件。

查看已删除但仍使用的文件：

lsof -b 2>/dev/null | grep deleted

您可能删除了大量文件 - 这本身不是问题。但单个删除的文件变大才是问题。

重新启动应该可以解决这个问题，但如果您不想重新启动，请检查所涉及的应用程序（lsof输出中的第一列）并重新启动或关闭看起来合理的应用程序。

如果你看到类似这样的内容：

zsh   1724   muru   txt   REG   8,17   771448   1591515  /usr/bin/zsh (deleted)

如果应用程序和删除的文件相同，则可能意味着应用程序已升级。您可以忽略这些占用大量磁盘空间的因素（但您仍应重新启动程序，以便应用错误修复）。

中的文件/dev/shm是共享内存对象，不会占用太多磁盘空间（我认为最多占用一个 inode 号）。它们也可以安全地忽略。命名的文件vteXXXXXX是来自基于 VTE 的终端仿真器（如 GNOME Terminal、Terminator 等）的日志文件。这些可以很大，如果你打开了终端窗口很多（我的意思是很多）正在输出的内容。

Answer

如果磁盘空间出现不可见的增长，那么罪魁祸首可能是已删除的文件。在 Windows 中，如果您尝试删除某个程序打开的文件，则会收到错误。在 Linux 中，该文件将被标记为已删除，但数据将保留，直到应用程序释放。在某些情况下，这可以用作一个干净整洁的方法- 应用程序崩溃不会阻止清理临时文件。

查看已删除但仍使用的文件：

lsof -b 2>/dev/null | grep deleted

您可能删除了大量文件 - 这本身不是问题。但单个删除的文件变大才是问题。

重新启动应该可以解决这个问题，但如果您不想重新启动，请检查所涉及的应用程序（lsof输出中的第一列）并重新启动或关闭看起来合理的应用程序。

如果你看到类似这样的内容：

zsh   1724   muru   txt   REG   8,17   771448   1591515  /usr/bin/zsh (deleted)

如果应用程序和删除的文件相同，则可能意味着应用程序已升级。您可以忽略这些占用大量磁盘空间的因素（但您仍应重新启动程序，以便应用错误修复）。

中的文件/dev/shm是共享内存对象，不会占用太多磁盘空间（我认为最多占用一个 inode 号）。它们也可以安全地忽略。命名的文件vteXXXXXX是来自基于 VTE 的终端仿真器（如 GNOME Terminal、Terminator 等）的日志文件。这些可以很大，如果你打开了终端窗口很多（我的意思是很多）正在输出的内容。

Question 2

补充一下 muru 的精彩回答：

df 显示磁盘大小，
du 显示文件内容的总大小。

也许您在 du 中看不到的是许多小文件的出现......（查看最后一列，df -i看看 inode（即文件）的数量是否也随着时间的推移而增加很多）

如果你碰巧有 1'000'000（1 百万）个 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_inodeinode 的大小......一百万个“1 字节”文件可能会占用几 GB 的磁盘使用量。

如果您有 1024 字节的块和另外 256 字节的 inode 大小，您的 1'000'000 个文件将被报告为大约 1Mb du，但在磁盘上将计为大约 1.25Gb（如所见df）！（或者甚至是 2Gb，如果每个 inode 也必须位于 1 个专用磁盘块上...我不知道是否是这种情况）

Answer