[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