Telnet / SSH connection timeout on LAN

Andrey Repin anrdaemon@yandex.ru
Sat Jul 11 02:50:00 GMT 2015


Greetings, Warren Young!

> On Jul 9, 2015, at 12:04 AM, Andrey Repin <anrdaemon@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...


More information about the Cygwin mailing list