Why is fsck_hfs slow on *journaled* HFS+
Great question.

Apple only journals filesystem changes and not the data, so when a full filesystem check is initiated, the catalog file, extents file, superblocks, and allocation counts are manually checked / cross checked / and optionally rebuilt or refreshed. The journal saves no time to check a volume - it only saves time if you lose power or connection when a filesystem metadata modification is being made. So, you might run fsck less often, but it doesn’t shorten the run time of fsck

Every single hard link is referenced / evaluated on the sending and receiving side.

This process is highly IO intensive, so if you have spinning disks, you could have weeks to check a 20 TB volume on a RAID if multiple disks are involved.

One nice benchmark is to check how many files are present on the volume in the information tab and watch Activity Monitor to see what the read and write IOPS and data rate are. Then you can compare that to the protocol (USB C and 3.0 and Thunderbolt are faster than any realistic storage you might have) so you know the progress is limited by the drive and not CPU or connection.

In your case, the sparsebundle adds negligible overhead, but Time Machine is the real crippler. It uses hard links so every single file may be referenced dozens or even hundreds of times. I have some Time Machine volumes that will never finish a fsck in that I won’t let then run for the weeks needed.

Instead, I let them be read only - set them on a shelf and only ever would get files off them or wipe them when I know I don’t need any files back from them.


Repair Time Machine sparsebundle that will no longer mount


Some people perform heroic surgery on Time Machine data to revive it. I prefer to buy another $100 drive and start over every 6 to 18 months, adding new fresh destinations and aging out my older destinations when they get close to filling.