Greetings, Warren Young! > On Jul 9, 2015, at 12:04 AM, Andrey Repin <anrdae...@yandex.ru> wrote: >> >>> rsync requires a pretty heavy network transaction to figure >>> out if files have changed. >> >> I'm rsync'ing about 15 gigabytes of my home directory with just a few megs of >> network exchange.
> “Just?” > That was my definition of “heavy”. Sorry, but you can't sync data without sending data. And these few megs is the actual data I generate daily. > 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. > Can you really handwave away megs of network I/O and potentially gigs of > disk I/O? Do you never use locate(1) instead of find(1)? Same issue. I normally know where my stuff is, so I don't need to `find` or waste space on `locate` hash tables. > On top of that, the OP wants to do this every time the machine becomes > idle. Even if it was idle a few seconds ago, did some work, and is idle > again, the OP wants all this work to be done all over again. > Horribly wasteful. > I believe Dropbox and its major competitors avoid the need for this tree > scan by hooking into the OS’s filesystem change notification API, so that > they don’t do any network or disk I/O until one of the files it is > responsible for changes. > That’s the right way. VSS would be the right way, but I still did not find time to research its extents. -- With best regards, Andrey Repin Saturday, July 11, 2015 05:35:21 Sorry for my terrible english...
