{"id":25778,"date":"2019-06-25T16:47:00","date_gmt":"2019-06-25T20:47:00","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=25778"},"modified":"2020-07-03T16:51:39","modified_gmt":"2020-07-03T20:51:39","slug":"superduper-3-2-5","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2019\/06\/25\/superduper-3-2-5\/","title":{"rendered":"SuperDuper 3.2.5"},"content":{"rendered":"

Dave Nanian<\/a>:<\/p>\n

So if that code was right, why the heck were some<\/strong> users getting occasional<\/strong> multiple runs? And why wasn’t it happening to us here at Shirt Pocket HQ?<\/p>

[…]<\/p>

Previously, in order to work around problems with Clean My Mac (which, for some reason, incorrectly disables our scheduling when a cleanup pass is run, much to my frustration), we changed SuperDuper to reload our LaunchAgents when it starts, in order to self-repair.<\/p>

[…]<\/p>

Readers may recall that launchd’s ThrottleInterval<\/code> doesn’t really control how often a job might launch, “throttling” it to only once every n<\/code> seconds. It actually forces a task to relaunch if it doesn’t run for at least n<\/code> seconds.<\/p>

It does this even if a task succeeds, exits normally, and is set up to run, say, every minute<\/strong>.<\/p>

[…]<\/p>

So, in 3.2.5, we’ve changed this so that rather than write a file “optimally”, maximizing the number of holes, we write it “accurately”. That is, we exactly<\/strong> replicate the sparse structure on the source. This speeds things up tremendously. For example, with a typical sparse docker image, the OS’s low-level copyfile<\/code> function takes 13 minutes to copy with full fidelity, rsync<\/code> takes 3 minutes and doesn’t provide full fidelity, whereas SuperDuper 3.2.5 takes 53 seconds and exactly replicates the source.<\/p><\/blockquote>\n\n

Previously:<\/p>\n