主页 / server / 问题 / 445445
Accepted
Jacek Konieczny
Asked: 2012-11-05 23:43:29 +0800 CST

tmpfs 填满了，尽管几乎不使用。我该如何调试

  • 772

我有一个带有 / on tmpfs 的系统。大多数 / 子目录都安装了 aufs，用只读的基本文件系统覆盖读写根文件系统（系统从只读介质启动）。早些时候，我使用unionfs而不是aufs。它一直正常工作，直到最近 tmpfs 开始填满。我不确定是什么触发了变化。它可能是 unionfs 到 aufs 的更改、内核升级或系统中的某些更改以及它如何访问文件系统。

无论如何，似乎是 tmpfs 的行为有些错误。

虽然系统不应该向 tmpfs 写入很多内容，但其中有相当一部分已经用完了：

# df -m /
Filesystem     1M-blocks  Used Available Use% Mounted on
tmpfs                200    50       151  25% /

尽管：

# du -smx /
2       /

这是我的测试系统，基本上什么都不做。当使用率迅速超过 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——没有变化。

linux

2 个回答

  1. Best Answer

    在 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/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

    注意使用统计数据是如何变化的。du显示添加了 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 上丢失的空间被恢复。所以，至少，我知道这是 aufs，而不是 tmpfs 的罪魁祸首。

    发生了什么

    知道应该责备什么，我在 aufs-users 邮件列表上描述了我的问题。我很快收到了第一个答案。来自 JR Okajima 的帮助我解释了丢失的 tmpfs 块发生了什么。

    确实是一个被删除的文件。由于文件未被任何用户空间进程打开或映射，因此未lsof在其中任何地方显示。/proc/<pid>/*这个文件，'xino 文件'，是 aufs 的外部索引节点号转换表，由内核 aufs 模块在内部使用。

    可以从 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

    但是，可以从 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

    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 空间不足问题……但我学到了很多东西。

    • 10

  2. 我已经看到这种情况发生在文件被删除但进程仍在保留文件的情况下，这意味着在进程重新启动之前空间不会被释放。我已经在 Apache 日志文件中看到了这一点。它似乎继续写入现在已删除的日志文件，直到重新启动后空间才被清除。

    要找出哪个进程可能保留已删除的文件，您可以尝试重新启动每个进程并查看是否清除了空间。如果是这样，您就找到了罪魁祸首。

    HTH

    • 2

相关问题