Periodically Time Machine verifies sparsebundle backups with fsck_hfs. When the sparsebundle is on a Time Capsule (TC) it does this by creating a partial and much smaller representation of the sparsebundle on the TC, transferring the result to the mac into
/private/var/db/com.apple.backupd.backupVerification
and then running fsck_hfs on it locally (it mounts the local sparsebundle as can be seen with diskutil list).
The problem is that it takes a very long time for fsck_hfs to verify this representation of very large TC sparsebundles (e.g. >24hrs).
[This leaves the timemachine process showing in the menu as if it was stuck 'verifying' with the real Time Capsule disk apparently no longer mounted under /Volumes – which confuses many into thinking the process has died]
fsck_hfs is launched by its parent process backupd with the parameters -f -n -x -E . There are various posts about fsck_hfs working much more efficiently if allowed to use more memory (-c option). By default (at least on my system) it seems to be limited to 3Gb.
My question is, is there anyway to pass a config that might cause backupd to launch fsck_hfs with the additional (-c) parameter and so run faster?
Best Answer
As far as I know, there's no configuration file or GUI part of the setup that you can use to force Time Machine to let
fsck_hfsuse more than the default amount of RAM for caching.There's however a kind of "workaround" for making this work anyway. You replace
/sbin/fsck_hfswith a new program (script or binary) that checks if it is run by Time Machine, and if so adds "-c 8G" (or whatever you want) to the command line parameters given to fsck_hfs. If it not run by Time Machine, just runfsck_hfswith the given parameters.If you're on a recent macOS, you'll need to disable SIP in order to replace
fsck_hfs.