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[…]
Bug HFS+ Mac macOS 15 Sequoia Storage
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。