[RndTbl] out of inodes

[Trevor Cordes]

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!