As a follow-up to the opera-ate-my-inodes problem discussed at the meeting, I checked a few things out and realized that this surely is a problem not limited to bad (or lazy) admin choices, for the following reasons:
1. People with separate /home partitions aren't spared: what if an app or malicious user writes to /var/tmp, which on 99% of systems is going to be on the same partition as /. So a separate /home won't spare you from / running out of inodes: all it takes is one sticky-bit dir in the whole tree where a non-root can write to have one non-root user/app starve the system of inodes.
2. The thought that you should create your fs's with massively more inodes than your usage pattern could ever use won't help either, as the user/app could create 0 byte files that eat an inode but never a fs block. You'd run out of inodes before you hit the reserved-root-du limit no matter how many inodes you created at fs creation time. (Not to mention the non-insignificant loss of usable disk space that occurs if you allocate many orders of magnitude more inodes than you will ever need.)
3. Quotas might be able to help, but I'm not talking about public systems here, I'm talking about my own personal home desktop. Surely no one is running quotas against themselves on their personal home system? And surely that can't be offered as a "sane" solution the average Joe is supposed to implement.
OK, here's the weirdest part: I just checked and my / is ext4! I thought Adam mentioned ext4 dynamically creates inode out of thin air (and I thought that too) like XFS? So why did I run out of inodes on a non-full (df) ext4 fs?
If this "bug" indeed affects ext4 then for sure I am filing a bug report. If it only affected "legacy" fs's like ext3 then I probably would just let it pass (and switch to ext4 if I hadn't already).
Thanks for everyone's input!