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