linux – tmpfs填满了,虽然很少使用.我该如何调试呢

概述我有一个带有/ on tmpfs的系统.大多数/子目录都安装了aufs,覆盖了只读基本文件系统的读写根文件系统(系统从只读介质引导).早些时候,我曾经使用unionfs而不是aufs.它一直运作正常,直到最近tmpfs开始填满.我不确定是什么引发了这一变化.它可能是aufs更改的unionfs,内核升级或系统中的一些更改以及它如何访问文件系统. 无论如何,似乎是tmpfs表现出某种错误. 虽然系统 我有一个带有/ on tmpfs的系统.大多数/子目录都安装了aufs,覆盖了只读基本文件系统的读写根文件系统(系统从只读介质引导).早些时候,我曾经使用unionfs而不是aufs.它一直运作正常,直到最近tmpfs开始填满.我不确定是什么引发了这一变化.它可能是aufs更改的unionfs,内核升级或系统中的一些更改以及它如何访问文件系统.

无论如何,似乎是tmpfs表现出某种错误.

虽然系统不应该为tmpfs写很多东西,但是相当多的东西用完了：

# df -m /filesystem     1M-blocks  Used Available Use% Mounted ontmpfs                200    50       151  25% /

而：

# du -smx /2       /

这是我的测试系统,基本上什么也没做.当使用率快速达到90％以上且系统崩溃时,生产系统就会出现问题.

我怀疑这些删除的文件仍然打开,但是：

# lsof | grep deleted

没有显示.

另一个想法是,一些文件被安装在它上面的文件系统掩盖,所以我尝试了这个：

# mount --bind / /mnt# du -sm /mnt2       /mnt

尽管如此,没有一丝48MB的损失.

如何找出正在使用我的tmpfs文件系统的内容？

系统信息：

# uname -rm3.4.6 i686

更新：我尝试过内核3.4.17和3.6.6 – 没有变化.

解决方法 在aufs维护者Junjiro Okajima的帮助下,我自己解开了这个谜团.

调试问题的第一步是以受控方式重现它.我花了一些时间(现在我想知道为什么这么多)才能发现,当通过aufs编写和删除文件时会出现问题.

再现问题

创建挂载点：

# 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/mntbin  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 onnone             1031128    24   1031104   1% /tmp/rw

/ tmp / rw中没有文件,但分配了24个块.仍然不是一个大问题.

我可以写一个文件到aufs,它将存储在/ tmp / rw中的tmpfs：

# dd if=/dev/zero of=/tmp/mnt/test bs=1024 count=100100+0 records in100+0 records out102400 bytes (102 kB) copIEd,0.000343903 s,298 MB/s# du -sk /tmp/rw100 /tmp/rw# df /tmp/rwfilesystem     1K-blocks  Used Available Use% Mounted onnone             1031128   128   1031000   1% /tmp/rw

请注意使用统计信息的更改方式.正如预期的那样,du show 100kB添加,但df输出中的’Used’值增加了104个块.

当我删除文件时：

# du -sk /tmp/rw   0   /tmp/rw# df /tmp/rwfilesystem     1K-blocks  Used Available Use% Mounted onnone             1031128    28   1031100   1% /tmp/rw

丢失了四个街区.

当我重复dd和rm命令几次时,我得到：

# df /tmp/rw                                         filesystem     1K-blocks  Used Available Use% Mounted onnone             1031128    36   1031092   1% /tmp/rw

越来越多的tmpfs块消失了,我不知道在哪里……

在我做同样的事情 – 直接在/ tmp / rw上的dd和rm没有丢失这种方式.在卸下aufs之后,tmpfs上丢失的空间被恢复了.所以,至少,我知道这是aufs,而不是tmpfs责备.

发生了什么事

知道应该责备什么,我在aufs-users邮件列表上描述了我的问题.我很快收到了第一个答案. The one from J. R. Okajima帮助我解释了丢失的tmpfs块发生了什么.

确实,这是一个已删除的文件.它没有被lsof或/ proc /< pID> / *中的任何地方显示,因为文件未被任何用户空间进程打开或mmaped.文件’xino文件’是aufs的外部inode号转换表,由内核aufs模块在内部使用.

可以从sysfs中读取文件的路径：

# cat /sys/fs/aufs/si_*/xi_path         /tmp/rw/.aufs.xino

但是,由于文件被删除,因此无法直接看到：

# ls -l /tmp/rw/.aufs.xinols: cannot access /tmp/rw/.aufs.xino: No such file or directory

但是,可以从deBUGfs中读取有关其大小和其他特殊aufs文件大小的信息：

# 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

详情见the aufs manual page.

解决方案

‘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-space问题……但我学到了很多东西.

总结

以上是内存溢出为你收集整理的linux – tmpfs填满了,虽然很少使用.我该如何调试呢全部内容，希望文章能够帮你解决linux – tmpfs填满了,虽然很少使用.我该如何调试呢所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。