我有一个tmpfs系统。 大多数/子目录的aufs被安装在覆盖读写根文件系统的只读基本文件系统（系统从只读介质启动）上。 此前，我曾经使用unionfs而不是aufs。 它一直在正常工作，直到最近tmpfs开始填满。 我不确定是什么引发了这个变化。 它可能是aufs更改，内核升级或系统中的某些更改以及如何访问文件系统的unionfs。
无论如何，它似乎是行为有点错误的tmpfs。
虽然这个系统不应该给tmpfs写很多东西，但是很多东西都用完了：
# df -m / Filesystem 1M-blocks Used Available Use% Mounted on tmpfs 200 50 151 25% / 而：
# du -smx / 2 /
这是我的testing系统，基本上什么都不做。 当使用率迅速达到90％以上，系统崩溃时，生产系统上的东西就会磨损。
我怀疑这些被删除的文件仍然打开，但：
# lsof | grep deleted
什么都没显示
另外一个想法是，一些文件被安装在其上的文件系统掩盖了，所以我尝试了这一点：
# mount --bind / /mnt # du -sm /mnt 2 /mnt
不过，没有一丝48MB的损失。
如何找出什么是我的tmpfs文件系统？
系统信息：
# uname -rm 3.4.6 i686
更新：我已经尝试了内核3.4.17和3.6.6 – 没有改变。
我亲自解决了奥秘，在aufs维护者，冈岛纯次郎的帮助下。
debugging问题的第一步是以受控的方式重现问题。 这花了我一些时间（现在我想知道为什么这么多），发现问题发生在通过aufs写入和删除文件时。
创build挂载点：
# cd /tmp # mkdir rw # mkdir mnt
安装tmpfs：
# mount -t tmpfs none /tmp/rw
安装aufs，用/ tmp / rw覆盖/ usr：
# mount -t aufs -n -o "br:/tmp/rw:/usr" none "/tmp/mnt"
现在我可以看到/ tmp / mnt下的/ usr内容：
# ls /tmp/mnt bin games include lib lib64 local sbin share src
我感兴趣的是下面的tmpfs使用/可用的空间：
# du -sk /tmp/rw 0 /tmp/rw # df /tmp/rw Filesystem 1K-blocks Used Available Use% Mounted on none 1031128 24 1031104 1% /tmp/rw
/ tmp / rw中没有文件，但分配了24个块。 仍然不是一个大问题。
我可以写一个文件到aufs，它会被存储在/ tmp / rw中的tmpfs上：
# dd if=/dev/zero of=/tmp/mnt/test bs=1024 count=100 100+0 records in 100+0 records out 102400 bytes (102 kB) copied, 0.000343903 s, 298 MB/s # du -sk /tmp/rw 100 /tmp/rw # df /tmp/rw Filesystem 1K-blocks Used Available Use% Mounted on none 1031128 128 1031000 1% /tmp/rw
请注意使用情况统计信息的变化。 如预期的那样，增加了100kB，但是df产出中的“使用”值增加了104块。
当我删除文件时：
# du -sk /tmp/rw 0 /tmp/rw # df /tmp/rw Filesystem 1K-blocks Used Available Use% Mounted on none 1031128 28 1031100 1% /tmp/rw
四个街区丢失了。
当我多次重复dd和rm命令时，我会得到：
# df /tmp/rw Filesystem 1K-blocks Used Available Use% Mounted on none 1031128 36 1031092 1% /tmp/rw
越来越多的tmpfs块消失了，我不知道在哪里…
我在那里做了同样的事情 – dd和rm直接在/ tmp / rw上没有任何东西是这样丢失的。 在卸载aufs之后，tmpfs上的空间被恢复了。 所以，至less，我知道这是aufs，而不是tmpfs的责备。
知道责怪什么，我在aufs-users邮件列表上描述了我的问题。 我很快就收到了第一个答案。 来自JR Okajima的那个人帮我解释了这个失踪的tmpfs街区正在发生什么。
这确实是一个被删除的文件。 在/proc/<pid>/*中没有显示lsof或任何地方，因为文件没有被任何用户空间进程打开或模拟。 文件'xino文件'是aufs的外部inode号码转换表，由内核aufs模块在内部使用。
该文件的path可以从sysfs读取：
# cat /sys/fs/aufs/si_*/xi_path /tmp/rw/.aufs.xino
但是，当文件被删除时，不能直接看到：
# ls -l /tmp/rw/.aufs.xino ls: cannot access /tmp/rw/.aufs.xino: No such file or directory
但是，有关其他特殊aufs文件的大小和大小的信息可以从debugfs读取：
# for f in /sys/kernel/debug/aufs/si_8c8d888a/* ; do echo -n "$f: " ; cat $f ; done /sys/kernel/debug/aufs/si_8c8d888a/xi0: 1, 32x4096 132416 /sys/kernel/debug/aufs/si_8c8d888a/xi1: 1, 24x4096 626868 /sys/kernel/debug/aufs/si_8c8d888a/xib: 8x4096 4096 /sys/kernel/debug/aufs/si_8c8d888a/xigen: 8x4096 88
细节在aufs手册页描述。
'xino文件'可以通过以下方式手动截断：
# mount -o remount,itrunc_xino=0 /tmp/mnt
在安装aufs时，可以使用trunc_xino选项来请求自动的xino文件截断：
# mount -t aufs -n -o "br:/tmp/rw:/usr,trunc_xino" none "/tmp/mnt"
我仍然不知道它是如何影响文件系统的性能，或者如果这真的会解决我在生产中的tmpfs空间问题，但是我学到了很多东西。
我已经看到这种情况发生在文件被删除的地方，但进程仍然持有文件，这意味着在重启进程之前，空间并没有被释放。 我已经看到这与Apache日志文件。 它似乎继续写入到现在删除的日志文件中，直到重新启动后才清除该空间。
为了找出哪些进程可能会被删除的文件，你可以尝试重新启动每个进程，看看是否清除空间。 如果是这样，你find了你的罪魁祸首。
HTH