我已经尝试过好几天了，没有运气。 在这个论坛和其他论坛上，我可以看到很多关于这个的讨论，但是没有一个解决scheme对我有用。
我目前的情况是，我有一些GB“失踪”，我无法自由或find任何地方。 我想这是一些像内存泄漏这样的问题，只有在重新启动时才能修复，但是我想问一下，如果有人有一个更好的想法，因为目前在该服务器上有几个客户。
以下是我在其他线程和我的特定输出中看到的一些命令：
Filesystem Size Used Avail Use% Mounted on /dev/sda1 19G 16G 1.8G 90% / tmpfs 384M 0 384M 0% /lib/init/rw udev 10M 1.2M 8.9M 12% /dev tmpfs 384M 0 384M 0% /dev/shm 4.8M /bin 27M /boot 0 /cdrom 1.2M /dev 8.8M /emul 504M /etc 4.0K /grubconf 88K /home 60K /images 0 /initrd.img 147M /lib 0 /lib32 0 /lib64 16K /lost+found 12K /media 4.0K /mnt 4.4M /opt 777M /proc 57M /root 4.7M /sbin 4.0K /selinux 4.0K /srv 0 /sys 4.0K /tmp 332M /usr 471M /var 0 /vmlinuz
(no output)
(no output)
-r-------- 1 root root 777M 2015-07-21 06:19 /proc/kcore -rw------- 1 root root 64M 2015-07-09 03:31 /sys/devices/pci0000:00/0000:00:06.0/0000:01:04.0/resource0 -rw-r----- 1 root adm 49M 2015-07-21 06:19 /var/log/auth.log -rw-r----- 1 root adm 174M 2015-07-19 06:25 /var/log/auth.log.1 -rw-rw---- 1 control mail 100M 2015-07-21 06:00 /var/mail/control
例如，如果你从du做math，你会得到几个GB，但是没有接近16GB的数字。
/是ext3。
操作系统是Debian 6.0
有什么我在这里失踪？
发生这种情况的原因有99.9％是因为一个或多个文件已被删除，但仍有一个正在写入旧文件句柄的进程。
当一个程序想要对一个文件执行I / O操作时，它要求内核“嘿内核，我想访问文件/bla.txt，我希望能够读写它”。 内核然后返回一个“文件句柄”，它是对可用于执行读写操作的文件的引用。
只要程序保持文件句柄处于打开状态，即使文件随后被删除，也可以继续写入。
当你对文件做些什么的时候，这通常会变得很明显，而且大部分时间都会像循环日志文件一样。 接下来会发生的事情是， df报告磁盘上的实际使用情况，其中可能包括正在写入的打开文件占用的空间。 另一方面， du翻遍了所有已知的文件名，并考虑到了他们的空间。 这可以less一些，因为删除的文件不再有一个文件名，因此du没有考虑到。
要查看这是否是你的问题，运行这个命令： lsof +L1 ，如果你看到任何文件名说'（（删除）'），那么你将需要停止输出的“命令”列中指定的进程，然后找出为什么它保持打开删除的文件。 一旦你弄清楚了，你可以采取措施阻止它的发生。
我只能想到两个原因：
使用dd将您的分区转储到可移动/networking磁盘，并在其他地方挂载/检查。 倾销时您可能会遇到一些不一致的情况，但很可能会很容易解决。