fsck_hfs Cache Exhaustion Bug
fsck_hfsin macOS Sequoia (version hfs-683.x) has a cache exhaustion bug that reports false corruption on large HFS+ volumes. On machines with 8 GB RAM, volumes of 24 TB or larger trigger “Couldn’t read node” errors during the extended attributes check.[…]
fsck_hfspre-allocates a cache at startup — a pool of 32KB blocks used for all disk reads. The size of this pool is determined by available system RAM[…][…]
BTCheckUnusedNodesraces through tens of thousands of free nodes, and every unique disk offset it touches gets aTag_tstructure allocated viacallocand inserted into the cache’s hash table. Each tag claims one 32KB buffer from the pool. When the release path runs, it returns the tag to the LRU list — but the LRU management doesn’t keep up with the rate of allocations.[…]
The irony: a function designed to verify filesystem integrity is itself broken — reporting phantom corruption on perfectly valid volumes.
I’m surprised that we keep seeing new HFS+ bugs. I would have thought that code would be frozen by now.
Previously:
Update (2026-06-08): Larry Yaeger:
hfs_catalog_check.py - Detailed HFS+ structural verifier
A read-only diagnostic that walks the catalog, extents-overflow, and attributes B-trees of an HFS+ volume and reports problems with more actionable detail than fsck_hfs provides[…]
2 Comments RSS · Twitter · Mastodon
Since updating to Sequoia last year I lost two HFS+ volumes. In both cases, they failed after running a routine disk first aid repair from a sequoia host. One became unmountable and had to be restored from a backup and has been working fine for ~9 months since then. The other can be mounted but the OS complains about corruption. Neither were as large (18 TB and 4 TB) as that medium post, so perhaps there are further problems.
Thank goodness we still have DiskWarrior. I'll be sure to go directly to that before I attempt repair on a Sequoia system. And that's if and when I downgrade my systems running macOS 13 or 14 to Sequoia.
