Otdfbt

According to this answer it is possible to mount at least tmpfs with "infinite" inodes.

Consider this specific (numbers chosen for example purposes, I know that they're not realistic) situation:

• The tmpfs partition is 50% used by volume


• 90% of that data is inodes (i.e. 45% of the disk is used by inodes, and 5% is used by "real" data)


• tmpfs was mounted with nr_inodes=1000
  


• all 1000 of those inodes are taken up by the inodes currently written

This means that the tmpfs is 50% full, but also that any attempt to write to it will result in an out of space error.

It seems to me that setting nr_inodes=0 (aka infinite inodes) would make this situation go away.

• Is there a reason that infinite inodes is not the default?


• What reasons are there to limit the number of inodes on a filesystem?

Usually (ex: ext2, ext3, ext4, ufs), the number of inodes a file system can hold is set at creation time so no mount option can workaround it.

Some filesystems like xfs have the ratio of space used by inodes a tunable so it can be increased at any time.

Modern file systems like ZFS or btrfs have no hardcoded limitation on the number of files a file system can store, inodes (or their equivalent) are created on demand.

Edit: narrowing the answer to the updated question.

With tmpfs, the default number of inodes is computed to be large enough for most of the realistic use cases. The only situation where this setting wouldn't be optimal would be if a large number of empty files are created on tmpfs. If you are in that case, the best practice is to adjust the nr_inode parameter to a value large enough for all the files to fit but not use 0 (=unlimited). tmpfs documentation states this shouldn't be the default setting because of a risk of memory exhaustion by non root users:

if nr_inodes=0, inodes will not be limited. It is generally unwise to
mount with such options, since it allows any user with write access to
use up all the memory on the machine; but enhances the scalability of
that instance in a system with many cpus making intensive use of it.

However, it is unclear how this could happen given the fact tmpfs RAM usage is by default limited to 50% of the RAM:

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.

Like Madhatter said, inodes take up some space, and it isn't a trivial amount when talking about using an infinite number of them.

The memory consumption for tmpfs inodes is not counted towards the allocated blocks of the mount. There can be no tmpfs usage that is "90% inodes", only the "real" data is counted.

A tmpfs mount of any size will continue to appear "empty" as long as none of its files contain any bytes. Total memory consumption for maintaining the mount can greatly exceed any size limit.

$ find /mnt | wc -l
60000
$ df -h /mnt
Filesystem Size Used Avail Use% Mounted on
tmpfs 4.0K 0 4.0K 0% /mnt

Therefore, to prevent memory exhaustion, both size= and nr_inodes= have to be limited. If a very large or no inode limit was set by default, a runaway process might stall the system without making the source of the issue easily determinable.