I'm not a habitual Mac user. I wanted to get a breakdown of disk usage on a Mac, so having installed ncdu via homebrew ages ago, I did sudo ncdu -x /. Realising it would take forever, I installed duc with brew install duc, set it to profile with sudo duc index -xpH /. (Flags: -x = don't cross filesystem boundaries, -H = count hardlinks once, -p = progress). This morning this 120GB Mac had managed to scan as much as 2TB. I killed the process and switched off WiFi, in case it had mounted the network drive, and tried again: same problem. I gave up and went back to ncdu: same problem. I accepted defeat and installed some graphical app which seems to do the job.

Question: where is all this data coming from? I'm familiar with hardlinks being double counted, but both duc and ncdu can correct for that. I've never seen behaviour like this on any Linux system; clearly, the Mac filesystem model is very different. What's going on?

(I realise that part of what's going on is my naively trying to use Linux tools on a Mac. I've corrected that. But I want to know what's happening at the filesystem level because I've never seen this scale of a problem before: if you forget to exclude special paths in Linux you might get a few MB of nonsense (although most just fail); hardlinks can give you more than you wanted, but not by that order of magnitude. Clearly, macOS exposes a very different underlying model.)

1 Answer 1


What’s going in in a nutshell is “crawling the filesystem type tools” need to be updated for APFS in general and snapshots, firm links specifically. Once that’s done, you’ll have a happier experience.

I would use those inside a user home folder and use a tool like Daisy Disk or the Apple disk space tools to locate files and allocations you don’t expect on a “system” basis.

Or you can dig into the APFS volume groups and learn when and where filesytem crawling tools can get caught in loops or dead ends or “worm holes” to other file systems (including user created loops and synthetic firmlinks).

  • 2
    Oh goodness, it really isn't just unix... ta. Some very neat things here like the overlay/sealed boot volume, but no wonder crawlers get horribly stuck in it. That also explains why I've never noticed before---I've always worked in subdirs of ~.
    – 2e0byo
    Mar 17, 2022 at 14:30
  • That's a good way of putting it @2e0byo and consider that iOS / iPadOS are also not just unix - they're a massive user base of CPU hours running and running....
    – bmike
    Mar 17, 2022 at 22:11

You must log in to answer this question.

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