[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