.. For linux.
I'd really like to see figures for the calculated effective wear-cost of this function against all others, and the speedup. Not that there won't be a benefit, but quantifying it would be interesting.
I think the "innovative use of rsync" thing is a bit breathless. rsync is good but its not the only mechanism to keep filesystems in sync and its not free: it hits the inode file buffer cache hard, and can cause other problems like cache ejection of real data paths. It also has risks, because it can be subverted (there was an analysis of this for it's use in RPKI to secure BGP)
The point here being that the file(s) modified are consistent, cached contents aside (which IIRC have highly deterministic file names in a structured subdir of sharded contents). If this is about backing cached content, maybe that demands a tuned daemon? It should be possible to checkpoint and do partial update without doing backing store checks against each file/block.
You could e.g. use zfs snapshots too. Block efficient.
