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