> Also as I think Wayne pointed out, using "-c" isn't very common in the first > place.
> transfer. The delay due to I/O wait is going to be orders of magnitude higher > than any reasonable hash computation. In a parallel life, I also mirrored some websites generated from database backends. For some unknown reason, they often changes embedded fixed length strings in the html, but the last-mod date didn't change. I never caught this till using -c for grins. Then I ran it against the entire filesystem and turned up some more interesting diffs. It was just a thousand or so small files so there wasn't much I/O time involved in -c. I've also compared find -ls's for grins [reported most recently, albeit indirectly as: Subject: Abysmal sparse file performance!] So the various use cases do exist out there. I've solved media file integrity with ZFS sha256 checksums on top of crypto block devices. And due to having some CPU to spare, still make and compare strong checksum indexes to catch new things as mentioned two paragraphs up. It's only marginally faster to do it separately than with rsync -c overhead. And the index is a bonus used for fastfind, etc. Anyways :) -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
