[RndTbl] out of inodes

Adam Thompson athompso at athompso.net
Fri Dec 13 00:54:52 CST 2013


On 13-12-12 04:21 PM, Trevor Cordes wrote:
> 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.

Playing devil's advocate here: ( / /var /tmp /etc /usr /home ) is the 
typically-recommended set of partitions.  I will point out, however, 
that most systems set up this way are far more sensitive to running out 
of file-creation-ability on /var than anywhere else, so your point 
actually remains valid.  (Also, "ln -s /var/tmp /tmp" is fairly common 
in those setups.)

> 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?

Actually, what I meant is that it didn't pre-reserve space on disk for 
the inodes, and only uses up space in the partition as needed, not that 
it would keep creating inodes out of thin air. Comparatively, ext2/ext3 
(IIRC) pre-allocated space in the partition for all the inodes that it 
would ever need.  Not 100% certain of this without checking.

Overall, yes, I agree, there *ought* to be a limit on inodes like there 
is on disk space, but... even more important would be if inode 
exhaustion generated a different error than ENOSPC.  Um... I just read 
errno(3), and I take that back: I would never want to be responsible for 
adding *more* error codes to that list.

-- 
-Adam Thompson
  athompso at athompso.net



More information about the Roundtable mailing list