This has been going on for a few years through several upgrades. In the Terminal when I type df -h the ifree numbers are ridiculously high and clearly off.


$ df /
Filesystem   512-blocks      Used Available Capacity iused               ifree %iused  Mounted on
/dev/disk1s1  489825072 442781368  39401000    92% 2253035 9223372036852522772    0%   /

The disks /private/var/vm and Android File Transfer Agent.app also have huge numbers for ifree.

System Information:

About This Mac: 
macOS Mojave
Version 10.14.6
MacBook Pro (Retina, 15-inch, Mid 2014)

$ uname -a
Darwin xxxxxxx.xxxx.xx.comcast.net 18.7.0 Darwin Kernel Version 18.7.0: Thu Jun 18 20:50:10 PDT 2020; root:xnu-4903.278.43~1/RELEASE_X86_64 x86_64

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 263-1 (size_tmax) 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).

| improve this answer | |
  • The macOS BSD version of df is different than GNU coreutils df. Different options as well. But your number analysis is right on the money. – James Brickley Jul 27 at 20:52
  • I didn't give the information that it didn't used to be this way. – Prof Huster Aug 4 at 15:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .