El artículo documenta el hallazgo de un bug en la utilidad fsck_hfs incluida en macOS Sequoia (versión hfs-683.x) que genera falsos positivos de corrupción en volúmenes HFS+ de gran tamaño. La investigación, realizada por el desarrollador Kivanc G, parte de un error persistente al verificar un disco duro externo de 24 TB formateado como HFS+ con journaling en un Mac mini M1 con 8 GB de RAM.
El síntoma es un mensaje "Couldn't read node #61432" durante la comprobación de atributos extendidos, seguido del código de error 12 (ENOMEM, memoria insuficiente). El fallo se reproducía de forma idéntica incluso en volúmenes recién formateados, lo que descartó de entrada una corrupción progresiva de datos. Para descartar problemas de hardware, el autor ejecutó la verificación en un segundo disco de 24 TB con una carcasa y un chip puente USB diferentes, obteniendo el mismo error en el mismo nodo, y monitorizó las operaciones de E/S con dmesg y fs_usage sin detectar anomalías.
El siguiente paso fue examinar las estructuras internas del sistema de archivos: la cabecera del volumen, la cabecera del árbol B de atributos (con nodos de 8.192 bytes y un total de 65.536 nodos, de los cuales solo 195 estaban en uso) y el mapa de bits de nodos. El nodo 61432, marcado correctamente como libre y lleno de ceros, no mostraba irregularidad alguna.
La búsqueda se desplazó al código fuente abierto de Apple en el repositorio hfs, donde la función BTCheckUnusedNodes recorre todos los nodos libres del árbol para verificar que contengan ceros. Cada nodo consultado reserva una etiqueta (Tag_t) y un búfer de 32 KB de la caché interna de fsck_hfs. El autor descubrió que en máquinas con 8 GB de RAM, la caché dispone de 32.768 bloques de 32 KB (1 GB), pero la gestión de la lista LRU no libera etiquetas con la misma rapidez con la que se asignan. Cuando todos los bloques quedan retenidos por etiquetas activas, CacheAllocBlock devuelve NULL y LRUEvict no tiene elementos que expulsar, lo que provoca que CacheLookup retorne ENOMEM (error 12).
Para confirmar la hipótesis, Kivanc G compiló una versión de fsck_hfs con instrumentación añadida en las funciones de caché, y la traza mostró el momento exacto del fallo: "LRUEvict: empty? ERROR: CacheRead: CacheLookup error 12". El bug se manifiesta en volúmenes HFS+ de 24 TB o más con 8 GB de RAM o menos, mientras que máquinas con 16 GB o más y versiones anteriores de macOS no se ven afectadas. Los datos del usuario están intactos: el fallo reside en la herramienta, no en el sistema de archivos.