This is the mail archive of the
mailing list for the Cygwin project.
Re: Telnet / SSH connection timeout on LAN
- From: Andrey Repin <anrdaemon at yandex dot ru>
- To: Warren Young <wyml at etr-usa dot com>, cygwin at cygwin dot com
- Date: Sat, 11 Jul 2015 05:38:38 +0300
- Subject: Re: Telnet / SSH connection timeout on LAN
- Authentication-results: sourceware.org; auth=none
- References: <1436142936994-119480 dot post at n5 dot nabble dot com> <7931485F-EEA3-4C1B-8B2C-E495EF5ED1A9 at etr-usa dot com> <1283519593 dot 20150709090453 at yandex dot ru> <5C24455B-3D28-4C6D-A77B-70BB5D67F0AA at etr-usa dot com>
- Reply-to: cygwin at cygwin dot com
Greetings, Warren Young!
> On Jul 9, 2015, at 12:04 AM, Andrey Repin <email@example.com> 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.
> 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
With best regards,
Saturday, July 11, 2015 05:35:21
Sorry for my terrible english...