tmpfs /run/user/1000 耗尽了 inode,但它只有 30 个文件

tmpfs /run/user/1000 耗尽了 inode,但它只有 30 个文件

所以今天我注意到 gui 程序生成了一条错误消息:

(FreeFileSync:21930): dconf-CRITICAL **: 11:46:39.475: unable to create file '/run/user/1000/dconf/user': No space left on device.  dconf will not work properly.

其中/run/user/1000atmpfs为用户的run文件夹。问题是上面有足够的可用空间:

$ df -h /run/user/1000
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           1.6G  120K  1.6G   1% /run/user/1000

那么为什么呢?然后我发现还有0剩余的空闲索引节点。

$ df -i /run/user/1000
Filesystem      Inodes   IUsed IFree IUse% Mounted on
tmpfs          2027420 2027420     0  100% /run/user/1000

太好了。但问题是:我根本找不到原因。因为有该驱动器上存在的文件很少, 如下所示:

$ echo $PWD ; find . | wc -l
/run/user/1000
30

……除此之外,还有很少有打开的程序仍然保留已删除的文件:

$ sudo lsof $PWD | grep deleted
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
albert    17684   id   72u   REG   0,69     1026  1200359 /run/user/1000/#1200359 (deleted)

只有阿尔伯特.而在albert退出之后,用完的INode数量(100%!)保持不变。

在 ubuntu 18.10 上。我的系统已经运行了很长时间没有重新启动。还没重启呢。很快就会这样做。看看是否可以清除错误。

[编辑]

du顺便说一句,这里是一个链接,显示和命令之间的输出差异df,涉及报告的已使用索引节点数:

https://gist.github.com/dreamcat4/6740c40bb313c1a016d35a0c00a8ab92

他们似乎意见不一致!

答案1

我们发现在某些情况下,docker-containers 会导致这种 inode 消耗:

sudo find /run/docker/libcontainerd -xdev -printf '%h\n' |
  sort | uniq -c | sort -k 1 -n | awk '$1 > 100'

  26170 ./130663143dafaf23866942e29a72742d4f869edb0dfc40331e0e1782f4b14a3a
  30472 ./5a7a4c88324c1a42a2e1ad835058347fab523d75481d2047ffabd4546c908873
  30472 ./fc2a4628f61d1607861f3de9f1ce312fb662e57ffaa1205c2e616ff7aa54c67a

重新启动每个容器会将这些值重置为合理的水平。

答案2

您可以增加重新安装时可用的 inode 数量。来自内核文档:

tmpfs 具有三个用于调整大小的挂载选项:

size:为此 tmpfs 实例分配的字节数限制。默认情况下是物理 RAM 的一半,没有交换。如果您的 tmpfs 实例过大,机器将死锁,因为 OOM 处理程序将无法释放该内存。

nr_blocks:与 size 相同,但以 PAGE_SIZE 为单位。

nr_inodes:该实例的最大 inode 数。默认值是物理 RAM 页面数量的一半,或(在具有 highmem 的机器上)lowmem RAM 页面数量的一半,以较小者为准。

这些参数接受表示千、兆和千兆的后缀 k、m 或 g,并且可以在重新安装时更改。

相关内容