Greetings, Warren Young! >>> Consider all the disk I/O required. In its default mode, rsync must do a >>> full directory tree scan on the directory to be transferred, on *both* ends. >>> For each file with a different mtime or size, it must then recompute all the >>> hashes in that file, again on both sides. >> >> Wrong. In default mode, rsync only care about timestamp and size. >> It will not go on hashing crusade unless explicitly told to.
> You misunderstood what I wrote. Given a changed mtime or file size, rsync > then must re-read the file on both sides in order to generate a series of > checksums on chunks of the file in order to determine which parts of the > file have changed, so that it transfers only the changes. See: > > https://en.wikipedia.org/wiki/Rsync#Determining_which_parts_of_a_file_have_changed > If you skip this step, you must transfer the entire file contents to the > other side, since a difference only in the mtime and/or file size doesn’t > tell you which parts of the file have changed. In my environment, a small touch to the original file cause changes throughout the entirety of its stored image. ('cause storage format is actually an archive, and a small change here and there in the source file cause massive shifts in the resulting image.) You see, it is a matter of application and environment. -- With best regards, Andrey Repin Monday, July 13, 2015 19:31:58 Sorry for my terrible english...
