On 10 July 2015 at 07:19, Warren Young <w...@etr-usa.com> wrote: > 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”. > > 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. > > 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. > > 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.
Dropbox etc work well if you have a fast and low latency upstream channel. Trying to backup even small changes over a 1.5 MB DSL (still the most common in the United States) can seriously affect any and all network activity. Heck even with a 20 MB uplink speed you are looking at serious delays to do backups of just general changes to a system. In situations where bandwidth is limited then the local rsync is the way to go. [If you can tie in a dump like behaviour via the OS filesystem change api then even better but local services would need to be what is looked at for a majority of places (at least in the US).] > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > -- Stephen J Smoogen. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
