所以今天我注意到 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/1000
atmpfs
为用户的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,并且可以在重新安装时更改。