I had a runaway non-root user process (Opera browser actually) exhaust all of the inodes on my / (root) filesystem (ext4) by creating millions of 10 to 50 byte cache files in /home (which is not a separate partition on my system).  Linux & ext4 happily allowed this program to cripple the whole system until I figured out a) inodes were exhausted and b) what app was causing it and where they all were, and c) rm -rf them all.

We all know filesystems like ext2/3/4 reserve a (tunable) amount of space for root use only if a disk fills beyond a certain threshold.  I find it shocking that a similar mechanism does not exist for inodes.  Most *NIX geeks I know also can't believe it.  Do you find it shocking too?

One could argue I should have /home on a separate partition, but this is a non-solution because all it takes is one user-writable directory in / (root) such as /var/tmp.  Sure, then you could say /var should be a separate partition, but let's be realistic: 95%+ of systems out there will not have a separate /home or /var partition (let alone both).  Also, no distros by default create separate partitions for all of these.

One could argue you should have your inode capacity be set so large it would be impossible to exhaust it before you run out of disk space.  That point is moot because a program could create 0 byte files, thus allowing exhaustion of inodes before free space (which would remain unchanged).  Besides, one should be allowed to tune their inodes at fs creation time to suit their usage habits as monitored over the years (such as looking at their usual NBPI and adding a 2 or 4X safety margin).

One could argue you could use quotas, but that seems unreasonable for the average guy (like myself) to do on their home desktop computer that only they use.

Can ext2/3/4 and the kernel be modified to reserve a (tunable) number of inodes for root just as it does for disk space?