在管理 Linux 系统时，我经常发现自己在分区已满后很难找到罪魁祸首。我通常使用du / | sort -nr，但在大型文件系统上，这需要很长时间才能返回任何结果。
另外，这通常可以成功地突出显示最严重的违规者，但我经常发现自己在更微妙的情况下求助于du不使用sort
，然后不得不在输出中进行搜索。
我更喜欢依赖于标准 Linux 命令的命令行解决方案，因为我必须管理相当多的系统，并且安装新软件很麻烦（尤其是在磁盘空间不足时！）
答案1
尝试ncdu，一个优秀的命令行磁盘使用分析器：
答案2
不要直接去du /。用于df查找对您造成影响的分区，然后尝试du命令。
我喜欢尝试的一个是
# U.S.
du -h <dir> | grep '[0-9\.]\+G'
# Others
du -h <dir> | grep '[0-9\,]\+G'
因为它以“人类可读的形式”打印尺寸。除非您的分区非常小，否则 grep 查找千兆字节的目录对于您想要的内容来说是一个非常好的过滤器。这将花费你一些时间，但除非你设置了配额，否则我认为事情就是这样。
正如 @jchavannes 在评论中指出的那样，如果您发现太多误报，则表达式可以变得更加精确。我采纳了这个建议，这确实使它变得更好，但仍然存在误报，因此只有权衡（更简单的 expr，更糟糕的结果；更复杂和更长的 expr，更好的结果）。如果输出中显示了太多小目录，请相应地调整正则表达式。例如，
grep '^\s*[0-9\.]\+G'
甚至更准确（不会列出 < 1GB 的目录）。
如果你做有配额，可以使用
quota -v
查找占用磁盘的用户。
答案3
首先，请使用以下的“摘要”视图du：
du -s /*
效果是打印每个参数的大小，即上例中的每个根文件夹的大小。
此外，两者GNUdu和BSDdu可以是深度限制的（但 POSIXdu不能！）：
GNU（Linux，...）：
du --max-depth 3BSD（苹果系统， …）：
du -d 3
这会限制输出显示到深度3。当然，计算和显示的大小仍然是整个深度的总和。但尽管如此，限制显示深度会大大加快计算速度。
另一个有用的选项是-h（GNU 和 BSD 上的单词，但再一次，不是仅 POSIX 上的du）“人类可读”的输出（即使用 KiB、MiBETC。）。
答案4
查找文件系统上最大的文件总是需要很长时间。根据定义，您必须遍历整个文件系统来寻找大文件。唯一的解决方案可能是在所有系统上运行 cron 作业以提前准备好文件。
另一件事是，du 的 x 选项对于防止 du 跟随挂载点进入其他文件系统很有用。 IE：
du -x [path]
我通常运行的完整命令是：
sudo du -xm / | sort -rn > usage.txt
该-m方法返回以兆字节为单位的结果，并将sort -rn首先对结果中最大的数字进行排序。然后，您可以在编辑器中打开usage.txt，最大的文件夹（以/开头）将位于顶部。