我们有我们的samba服务器（ubuntu 8.04 ltr）份额填补了前一天，但当我去看看它，我不能看到任何股份必须对他们很多
我们有5组分享，然后每个用户有一个单独的份额
一个用户有22gig的东西，其他一些人有10-20mb的东西，其他人都是空的
所以也许总共26gigs
我昨天删除了几个文件，今天释放了大约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，所以我道歉，如果这不是很好解释）
（这是一个以Linux为中心的答案，其他的UNIX变种可能会有所不同。）
有两个与您的问题相关的信息：（1）哪些文件填满了您的文件系统，（2）哪些进程正在写入这些文件。
下面，当我把$字符放在命令中时，这可能是一个你需要replace一个实际值的占位符。 希望很明显，在哪里做，哪里不要。
请注意，在大多数文件系统types中确实有两个资源可以被单个文件使用：元数据（例如inode）和真实数据。 你可以看到inode的数量（searchGoogle的定义，但它们是构成你的文件的结构的“指针”），使用如下命令：
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来摆脱这个问题。
find可能填满文件系统的进程的最直接的方法是运行一个命令，如：
fuser -c $file_system 2>/dev/null
…它会告诉你为给定的文件系统打开文件描述符（文件和networking套接字）的进程的PID（ 2>/dev/null部分摆脱了一些你不需要的信息）。 您可能只能从这些PID中推断哪个进程正在填满您的文件系统。 通过以下方式search进程：
ps -ef | grep $pid
你也可以尝试运行这个命令，它会给你更多的细节（并帮助识别在磁盘上没有相应文件名的打开文件 – 我在上面提到过）：
sudo lsof $file_system | grep $directory_filling_up
…如果您已经从fuser命令中识别出可疑PID，则可以这样做：
sudo lsof -p $pid
fuser和lsof的问题是它们只能在您运行命令时给您一个系统的快照。 如果冒犯的过程在你运行的时候没有发生，那么你的运气不好。 您可以通过反复运行并保存输出来反击。 这将需要通过输出读取模式，或编写一个程序来为你做。 另一种方法是使用像SystemTap这样的工具。 SystemTap允许你捕捉各种有用的信息，并且是“可编程的”。 它甚至还附带了一些示例源文件，可以让您了解哪些进程在某个时间段内写入了哪些文件。 这将是完美的，但它是一个先进的工具，需要大量的Linux知识。
一旦你确定了违规程序，你可以杀死（也许重新启动它们）。 如果进程与操作系统或者一些打包好的软件相关联，那么可能会有重启的机制，但这取决于你的Linux发行版（我认为Ubuntu会允许你运行/etc/init.d/$init_script restart ，但你必须检查你的发行版的文档）。 否则，你可以用kill $pid或kill -9 $pid来杀死它，如果它不行为的话。 注意如果你需要重新启动它（你可能需要参考这个软件的文档），这个过程是怎么运行的（例如ps -ef显示的是什么参数）。
使用du来追踪包含正在填充磁盘的文件的目录。
cd / du -h --max-depth 1
会告诉你哪个目录在/使用最多的空间。 遍历运行du命令的文件系统find罪魁祸首。
例如
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规范将select已经被解除链接的打开的文件。 格式为+L1 <file_system>的规范将在指定的文件系统上select未链接的打开文件。
有些东西正在填满/分区。 这可能是在/var/log ，或在/home 。 这取决于你的设置。 也看看你的用户有权访问的地方。
在每个有问题的目录中运行以下命令。 这将向您展示空间最大的消费者的子目录。
cd /directory du -cks -x * .* |sort -n
这个想法是从O'Reilly公司的Linux Server Hacks的ducks脚本（ du -cks ）中借用的。 我经常运行这个命令。
根据我的经验，这几乎总是由于大的日益增长的日志文件。 在这种情况下，使用Logrotate ，并确保使用压缩 。 使用默认压缩率的gzip压缩，您的日志文件将会变小80-95％（1GB / var / log / messages可以轻松压缩到200MB或更less）。 这会给CPU带来适量的负载，但是我很less看到这会影响服务器的真实性能。 有些人更喜欢使用Bzip2压缩，或者使用gzip --best但是根据我的经验，这会导致很多CPU开销，但是没有什么好处。 gzip与默认的比例通常是足够好的。
显然，这个问题有时是由于用户做坏事。 使用上面的du命令find罪魁祸首。
我会使用du命令来查看哪些目录占用更多空间，哪些程序正在使用该空间。 如果你可以运行graphics应用程序， 有一些很好的将有助于总结du的输出，如KDirStat。
可能的罪魁祸首是日志，但这里是一个命令，将按照大小sorting最近修改（或创build）的文件：
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文件进行sorting。
（编辑）要监控增长，请使用gt5
sudo aptitude install gt5 cd / gt5
一天后 寻找±标志
gt5
日志文件可能正在填满您的硬盘驱动器。 使用logrotate来停止。
感谢大家的帮助
事实certificate，罪魁祸首是隐藏的每个共享导演隐藏的.recycler文件夹。
如果你做了一个ls -a你可以看到他们。