3

So today I bother notice an error message being generated by gui program:

(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.

Where /run/user/1000 is a tmpfs for the user's run folder. Thing is that there was plenty of free space on it:

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

So why then? Well then I discover that there are 0 free inodes remaining.

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

OK great. However the problems is this: I simply cannot find out the reason for this. Because there are very few files exisiting on this drive, as shown below:

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

...and other than that, there are very few open programs that are still clinging onto deleted files:

$ 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)

Only albert. And after the quitting of albert, the number of used up INodes (100% !) remained the same.

On ubuntu 18.10. My system has been up for quite a long time without a reboot. Still haven't rebooted yet. Will do this soon. And see if that clears the error.

[edited]

BTW, here is a link to show the difference in output between the du and df commands, in regards to the reported number of used inodes:

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

They do not seem to agree with each other!

Improve this question
1

2 Answers 2

Reset to default
1

We found that in some instances, docker-containers will cause this inode consumption:

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

Restarting each container reset these values to reasonable levels.

Improve this answer
0

You can increase the number of inodes available on a remount. From the kernel documentation :

tmpfs has three mount options for sizing:

size: The limit of allocated bytes for this tmpfs instance. The default is half of your physical RAM without swap. If you oversize your tmpfs instances the machine will deadlock since the OOM handler will not be able to free that memory.

nr_blocks: The same as size, but in blocks of PAGE_SIZE.

nr_inodes: The maximum number of inodes for this instance. The default is half of the number of your physical RAM pages, or (on a machine with highmem) the number of lowmem RAM pages, whichever is the lower.

These parameters accept a suffix k, m or g for kilo, mega and giga and can be changed on remount.

Improve this answer
3
  • 1
    While true, this doesn't explain why the OP has so many used inodes which seems to be the main thrust of the question.
    – terdon ♦
    Commented Jan 3, 2019 at 12:42
  • Rather ironically, looking back to what I wrote yesterday it seems I never actually asked a specific question! But yes: increasing the number of inodes isn't actually going to help very much if they all just get used up again anyhow. And there no actual reason being presented here to justify that if 2027420 is being consumed by only 30 files. Then doubling that number of available inodes will not just consume all the extra new inodes too. Hence then the 'why?', must I really have to ask!!??!!
    – Dreamcat4
    Commented Jan 4, 2019 at 7:26
  • Given the "can't stat" error, have a look at this link
    – JRFerguson
    Commented Jan 4, 2019 at 16:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .