I wonder if this is why recent versions of macOS performs so poorly on old HDD-based MacBooks. The difference between my work's 2012 MacBook (HDD) and my personal 2015 (SSD) MacBook is like night and day. Most apps open in a second on my SSD MacBook yet take up to a minute to open on my employer's HDD MacBook. It's not just this MacBook, I also see the same on a work iMac as well. Such a shame as these older machines previously didn't run so slowly.
The author worked very hard to determine the root cause of the problem but he was stymied because the APFS source code is not available. Why not? Apple has open-sourced the Swift compiler with great success, but there seems to be no movement within Apple to open up other system software components.
I'm too late to the thread, but wonder if locking might have to do with updating access times on the dirs on read--that would help justify a read-only workload taking some sort of exclusive lock. The "fix" there would be something like relatime to get atimes set infrequently.<p>There're def a ton of other possibilities. Some locking could be overbroad, like an exclusive lock where a reader lock would be enough. I don't see super-strong evidence that any locks involved are actually <i>global</i>, just that they're under contention here. And I can understand shipping a product with somewhat excessive locking because perf issues with specific workloads are a better problem to have with your shiny new FS rollout than data loss.<p>Anyway it's mostly shooting in the dark for us here (though cool some folks disassembled the functions), but there are some shots in the dark that look different from what I could find in the comments already here :)
Absolutely <i>nothing</i> there indicates the presence of global kernel locks. <i>readdir</i> (obviously!!!) needs to hold a lock, it’s not global, it’s per-DIR.
As someone who used to work on BitKeeper, I'm tickled to see a more popular SCM's test suite as a kind of de facto filesystem benchmark -- confirming what we had been observing ourselves forever.