前几天，我们的 samba 服务器（ubuntu 8.04 ltr）共享已满，但当我查看时，我发现没有哪个共享有太多内容
我们有 5 个群组共享，每个用户都有一个个人共享
一个用户有 22GB 的东西，其他几个用户有 10-20MB 的东西，其他人都是空的
所以可能总共 26gig
我昨天删除了几个文件，释放了大约 250mb 的空间，今天当我检查它时，它又完全满了，我删除了一些旧文件，释放了大约 170mb 的东西，但我可以看到它在可用空间中慢慢减少。
我一直在跑df -h
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 241690180 229340500 169200 100% /
varrun 257632 260 257372 1% /var/run
varlock 257632 0 257632 0% /var/lock
udev 257632 72 257560 1% /dev
devshm 257632 52 257580 1% /dev/shm
lrm 257632 40000 217632 16% /lib/modules/2.6.24-28-generic
/易挥发的
我该怎么做才能找出到底是什么占用了我的硬盘空间？（我对 unix 还不是很熟悉，所以如果没有解释清楚，我深表歉意）
答案1
（这是针对 Linux 的答案。其他 UNIX 变体可能有所不同。）
有两条信息与您的问题相关：（1）哪些文件正在填满您的文件系统，以及（2）哪些进程正在写入这些文件。
笔记
下面，当我将$字符放入命令中时，这可能是一个占位符，您需要在其中替换一个实际值。希望您能清楚地知道在哪里可以替换，在哪里不能替换。
哪些文件？
请注意，大多数文件系统类型中实际上有两种资源可被单个文件使用：元数据（例如 inode）和实际数据。您可以使用以下命令查看 inode 的数量（在 Google 上搜索定义，但它们是指向构成文件的结构的“指针”）：
df -i
...正如您所知，如下所示将显示真实数据所使用的空间：
df -h
另外，请注意文件系统空间可能会被磁盘上不存在的文件占用。这些文件仍处于某个进程的打开状态，但已被删除（我们将在下面介绍）。
确定了完整的文件系统后，您需要开始查找大量小文件、少量大文件或两者兼有。元数据资源耗尽通常是由于小文件过多造成的，而实际数据资源耗尽通常是由于少量大文件造成的。我喜欢使用以下命令来帮助查找大文件：
sudo find $file_system -mount -ls | awk '{print $7, $11}' | sort -rn > $output
...这个命令可以帮助查找包含大量小文件的目录（更新：：添加了空终止符以改进文件名处理）：
sudo find . -mount -print0 | xargs -0n 1 dirname | sort | uniq -c | sort -rn > $output
...请注意，这些命令可能需要一段时间才能运行，并且会执行大量 I/O，具体取决于情况。运行后，您可以通读$output以查找有问题的文件或目录。每个文件或目录的名称和位置可能会提示您数据来自何处，但需要一些 Linux 经验。
一旦确定了罪犯，你就可以rm $file摆脱问题。
哪些流程？
查找可能填满文件系统的进程最直接的方法是运行以下命令：
fuser -c $file_system 2>/dev/null
... 它将告诉您具有给定文件系统的打开文件描述符（文件和网络套接字）的进程的 PID（该2>/dev/null部分删除了一些您不需要的信息）。您可能能够仅从这些 PID 推断出哪个进程正在填满您的文件系统。使用以下命令搜索进程：
ps -ef | grep $pid
您还可以尝试运行此命令，它将为您提供更多详细信息（并帮助识别磁盘上没有相应文件名的打开文件 - 我上面提到过这一点）：
sudo lsof $file_system | grep $directory_filling_up
...如果您从命令中识别出可疑 PID fuser，您可以执行以下操作：
sudo lsof -p $pid
fuser和的问题lsof在于，它们只能提供运行命令时的系统快照。如果运行它们时有问题的进程没有写入，那你就没戏了。你可以通过在一段时间内反复运行它们并保存输出来解决这个问题。这将需要通读输出以找到模式，或者编写一个程序来为你做这件事。另一种方法是使用类似系统水龙头SystemTap 允许您捕获各种有用的信息，并且是“可编程的”。它甚至附带一些示例源文件，可让您查看在一段时间内哪些进程正在写入哪些文件。这将是完美的，但它是一种高级工具，需要大量的 Linux 知识。
一旦确定了有问题的进程，您就可以终止（并可能重新启动它们）。如果该进程与操作系统或某些打包好的软件相关联，则可能会有重新启动它们的机制，但这取决于您的 Linux 发行版（我认为 Ubuntu 将允许您运行类似 的程序/etc/init.d/$init_script restart，但您必须查看发行版的文档）。否则，如果它没有运行，您可以使用kill $pid或终止它kill -9 $pid。请注意进程的运行方式（例如， 中显示的参数是什么ps -ef），以防您需要重新启动它（您可能需要参考该软件的文档）。
答案2
用于du追踪包含填满磁盘的文件的目录。
cd /
du -h --max-depth 1
将显示 / 中哪个目录占用了最多的空间。运行 du 命令遍历文件系统以找到罪魁祸首。
例如
cd /
du -h --max-depth 1
显示 /usr 占用了系统已使用的 3.5G 中的 2.3G。
cd /usr
du -h --max-depth 1
显示 /usr/lib 使用了 /usr 中 2.3 中的 1.1G ...
这也可能是由于已删除的打开的文件造成的。
您可以使用lsof查找已打开但未链接（已删除）的文件
lsof +L1
应该可以解决问题。正如手册页所述：
格式为 的规范
+L1将选择已取消链接的打开文件。格式为 的规范+L1 <file_system>将选择指定文件系统上未链接的打开文件。
答案3
有东西正在填满 / 分区。可能是/var/log或 中的某些东西/home。这取决于您的设置。还要查看您的用户可以访问的位置。
在每个相关目录中运行以下命令。这将向您显示占用空间最大的子目录。
cd /directory
du -cks -x * .* |sort -n
这个想法借鉴了ducks剧本（du -cks）Linux 服务器黑客来自 O'Reilly。我经常运行这个命令。
根据我的经验，这几乎总是由于日志文件很大且不断增长而导致的。在这种情况下，使用日志旋转， 和确保使用压缩。使用默认压缩率的 gzip 压缩，您的日志文件将缩小 80-95%（1GB 的 /var/log/messages 可以轻松压缩到 200MB 或更小）。这会给 CPU 带来中等程度的负载，但我很少看到这会影响服务器的实际性能。有些人更喜欢使用 Bzip2 压缩，或者使用，gzip --best但根据我的经验，这会导致大量 CPU 开销而几乎没有额外的好处。gzip使用默认比率通常就足够了。
显然，这个问题有时是由于用户做了坏事造成的。使用du上面的命令来找到罪魁祸首。
答案4
可能的罪魁祸首是日志，但这里有一个命令可以按大小对最近修改（或创建）的文件进行排序：
D=$(date --rfc-3339 date);
sudo sh -c 'find / -xdev -mtime -1 -type f -print0 |xargs -0 du -0sbc' \
|tee ~/recent-files.$D |sort -zn |tee ~/recent-by-size.$D |xargs -0n1
您可以每天运行此命令；可能有一种方法可以执行一些 SQL 式的操作来按每日增长情况对这些文件进行排序。
（编辑）要监测增长，使用GT5
sudo aptitude install gt5
cd /
gt5
一天后；寻找 ± 符号
gt5