tmpfs running out of inodes ENOSPC: no space left on device

caotic · 2022-01-05 00:21:57

How can I increase the inode amount for my /tmp directory

So I am using this npm package called ganache-cli creates a massive amount of tiny files on /tmp/tmp-[generated keys]

After a few hours of usage the tool stops working with this error

AssertionError: expected promise to be fulfilled but it was rejected with 'Error: Returned error: ENOSPC: no space left on device, open \'/tmp/tmp-366722oh2I0A6O8wbj/_tmp/tmp-366722756Alp25FVgz\''

Now my /tmp directory still has some space left, but the tool seems to use all the FS inodes.

$ df -h /tmp/
Filesystem Size Used Avail Use% Mounted on
tmpfs 16G 4.4G 12G 28% /tmp

$ df --inodes /tmp/
Filesystem Inodes IUsed IFree IUse% Mounted on
tmpfs 1048576 1048576 0 100% /tmp

Found an article and it suggesting updating the `nr_inodes` for the /tmp entry on the /etc/mtab.
I don't know if I should be editing this file by hand or do I need some util for it, the restrictions on the file hint that I should be running something else (or that it is not possible)

Not sure where this values could have been set up on the linux installation, but I hope I don't need to do something to elaborate to fix it.

Last edited by caotic (2022-01-05 00:27:49)

Morn · 2022-01-05 01:10:31

I think it would be better to point that npm tool to a different directory. /tmp is a RAM disk in Arch Linux, so if a program needs several GB of tmp space, it will eat all of your RAM, which is probably not what you want. Even yay can be a problem if it tries to compile a large AUR package in /tmp and runs out of space…

caotic · 2022-01-05 03:37:28

Morn wrote:

I think it would be better to point that npm tool to a different directory. /tmp is a RAM disk in Arch Linux, so if a program needs several GB of tmp space, it will eat all of your RAM, which is probably not what you want. Even yay can be a problem if it tries to compile a large AUR package in /tmp and runs out of space…

Thanks this is something that I will try.
However I am happy with it being stored in ram as I have enough to spare, and I asume it runs faster on /tmp (The task is super slow (I estimate it running for aroud 5 hours plus I belive it will shorten my ssd lifespan)

Xyne · 2022-01-05 05:35:23

Add an entry for /tmp in /etc/fstab with the required mount options if you need a persistent setup, or just use the mount command to remount the partition with the higher inode limit when you need it.

caotic · 2022-01-05 07:42:46

Xyne wrote:

Add an entry for /tmp in /etc/fstab with the required mount options if you need a persistent setup, or just use the mount command to remount the partition with the higher inode limit when you need it.

Thanks, will try that out.

Last edited by caotic (2022-01-05 07:50:13)

frostschutz · 2022-01-05 08:52:19

It might be better to use a dedicated ram disk or loop mount a filesystem image on tmpfs, using a filesystem that can handle small files well.

For small files, tmpfs has tons of overhead per file. The default limits of tmpfs are already very generous - too generous, if you use multiple instances and fill them all up (crashes the system once tmpfs uses more resources than available).

If your application generates a million files per hour in tmpfs, then you'll run out of ram within a day even if you throw 128GB RAM at it... maybe a database would do a better job here than a filesystem.

If it stops generating more files at some point and you don't mind wasting over 4G of RAM per million files, then it's maybe fine...

Last edited by frostschutz (2022-01-05 09:06:43)

caotic · 2022-01-07 06:17:12

frostschutz wrote:

It might be better to use a dedicated ram disk or loop mount a filesystem image on tmpfs, using a filesystem that can handle small files well.
For small files, tmpfs has tons of overhead per file. The default limits of tmpfs are already very generous - too generous, if you use multiple instances and fill them all up (crashes the system once tmpfs uses more resources than available).
If your application generates a million files per hour in tmpfs, then you'll run out of ram within a day even if you throw 128GB RAM at it... maybe a database would do a better job here than a filesystem.
If it stops generating more files at some point and you don't mind wasting over 4G of RAM per million files, then it's maybe fine...

I don't own that applciation, i can't suddenly change how it stores its state. I appreciate the suggestion, but that is simply a solution for a different problem.

Last edited by caotic (2022-01-07 06:17:48)

Lone_Wolf · 2022-01-07 11:02:46

https://github.com/trufflesuite/ganache … er#options indicates there's a db_path option that allows to select where the chain database is stored.

Perhaps you can use that to workaround the issue ?

Arch Linux

#1 2022-01-05 00:21:57

tmpfs running out of inodes ENOSPC: no space left on device

#2 2022-01-05 01:10:31

Re: tmpfs running out of inodes ENOSPC: no space left on device

#3 2022-01-05 03:37:28

Re: tmpfs running out of inodes ENOSPC: no space left on device

#4 2022-01-05 05:35:23

Re: tmpfs running out of inodes ENOSPC: no space left on device

#5 2022-01-05 07:42:46

Re: tmpfs running out of inodes ENOSPC: no space left on device

#6 2022-01-05 08:52:19

Re: tmpfs running out of inodes ENOSPC: no space left on device

#7 2022-01-07 06:17:12

Re: tmpfs running out of inodes ENOSPC: no space left on device

#8 2022-01-07 11:02:46

Re: tmpfs running out of inodes ENOSPC: no space left on device

Board footer