[RndTbl] out of inodes

Trevor Cordes trevor at tecnopolis.ca
Fri Dec 13 02:25:52 CST 2013

On 2013-12-13 Adam Thompson wrote:
> Playing devil's advocate here: ( / /var /tmp /etc /usr /home ) is the 
> typically-recommended set of partitions.

Not anymore, not on Linux.  I don't know of a single distro, not even
enterprise-grade ones, that do this by default during install, or even
recommend it in their deployment guides.  Yes, this used to be
recommended on big-iron, at places like the U of M, but no one
realistically does this anymore on standalone desktops or servers
(unless for reasons of network-boot, xterms, etc).  I'd say having that
many partitions would make one as weird as me with my tuning of inode
quantities to match my historic usage patterns!

> point actually remains valid.  (Also, "ln -s /var/tmp /tmp" is fairly
> common in those setups.)

Fedora, and thus Red Hat (and probably others), are explicitly moving
to a shm /tmp and a disk-based /var/tmp, emphatically snubbing the old
"ln -s /var/tmp /tmp" paradigm.

Mind you, I'm not saying I agree with them, I'm just reporting the
news.  (The moment I found out /tmp was shm I changed it back to a
real disk partition.)

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

Ah!  Thanks for clarifying.  As an aside, I am 100% sure XFS does
dynamic inode quantity and space allocation, meaning you have unlimited
inodes (until disk space runs out).  It makes df -i rather interesting
(and useless).  Not that I'd ever contemplate changing my / to XFS!!!

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


More information about the Roundtable mailing list