Terminal Disk Free `df` returns Huge `ifree` free inodes

Solution 1:

My best guess is that these are filesystems that do not have inodes (the vast majority of modern filesystems don't, actually pretty much only old Unix filesystems do), and so the filesystem driver just synthesizes an arbitrary number because the 50 year old API says the driver must provide a number of free inodes even though modern filesystems haven't had them in a decade.

In particular, I am assuming that your / filesystem is APFS, which is indeed neither a traditional Unix filesystem (it was designed specifically for macOS) nor an old filesystem (it was announced in 2016). APFS is fully 64 bit, and as far as I know, it doesn't use a traditional inode-based scheme. Actually, the entire design of APFS and the way it intersects multiple layers of the traditional Unix filesystem, VFS, and block device stack, is very much non-traditional, and much more reminiscent of ZFS and the Be filesystem (which is no surprise since the designer of BeFS works at Apple now).

Note that the number you showed is very close to the maximum 64 bit signed integer (9223372036854775807), or in other words, it is close to the maximum of size_t in a 64 bit version of Darwin. In fact, the sum of used and free inodes is exactly 9223372036854775807. So, what is happening here, is that the filesystem driver simply synthesizes 2⁶³-1 (size_t_max) inodes for use.

Presumably, when you say that "it has been going on for a few years", you are talking about the move from 32 bit to 64 bit Darwin, and before that, the numbers were closer to 2147483647, which is of course the maximum for size_t in 32 bit Darwin.

For fun, you might download the open source Darwin source code from Apple and compile a 32 bit version of df, and I bet you, the numbers you will see are 2253035 and 2145230612 (2147483647 - 2253035).