--track-renames doesn't perform as well in synchronization between local file systems; it seems faster to leave it off and re-copy files. Is this because of the checksum calculation and comparison on both ends? And tracking renames with cloud storage is faster because the checksums are already computed and stored at that end? Which makes me wonder: is there a local file system that includes storage of hashes to speed up synchronization between local systems (e.g. internal to USB drive)? And as I thought that and wrote this, it occurred to me to do some googling and I found a comparison of file system capabilities. Does rclone leverage the checksums stored in those file systems? Thanks!
Yes most likely. Rclone doesn't store checksums for the local file system it calculates them again each time.
That is correct.
Interesting idea...
I did a bit of research on ZFS since that is reasonably popular - here are its supported checksums: https://github.com/zfsonlinux/zfs/wiki/Checksums
Unfortunately none of those overlap with any supported by the existing backends
- MD5
- SHA-1
- Whirlpool
- CRC-32
- DropboxHash
- MailruHash
- QuickXorHash
So I think this would be possible for a small number of file systems.
There are some other ways to solve slowness of --track-renames
- don't use size+checksum to match, use size+modtime (say)
- this would be much faster but might be open to false positives
- store a db of file path, modtime, size and checksum to speed up repeated checksum calculations