True, correction accepted, covering my head with ashes in shame ;) We do use a custom-built package of rsync-3.0.5 with a number of their standard contributed patches applied. To be specific, these:
checksum-reading.diff checksum-updating.diff detect-renamed.diff downdate.diff fileflags.diff fsync.diff netgroup-auth.diff Speaking of which, I should also suggest that after your cycles of "incremental" or "partial" rsync'ing are complete (which protects longterm outstanding IO against intermediate problems), you should rerun the same rsync command adding a "-cn" flag. This way both sides will calculate and compare checksums on their copies of files, and any files broken during transfer will be reported (and updated if you remove the "-n" flag). If by using "-cn" you find any files broken during transfer, check both versions. It may quite be possible that during these intensive operations the original disk's bits flipped. So in fact your new copy may be (or not be) the better half. If this is a distro archive with pre-existing checksums (md5sums) available, they would certainly help you decide which copy is the good one (or neither one is, as it happens sometimes). If this is a consumer multimedia archive with files in formats resistant to damage (MP3, MP4, JPEG to a lesser degree) you probably don't care much for an occasional noise glitch or a "green frames" artefact. Or you do :) Finally, the rsync flag "--sumfiles" (I'm not certain whether it's stock or from some of the patches) specifically allows you to create .rsyncsums files in each directory to speed up future synchronizations. Since on non-ZFS either the original file or its checksum file can degrade undetected, recalculating and checking the validity of these checksums once in a while is a good idea to detect errors crawling in. // HTH, Jim -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
