delorie.com/archives/browse.cgi | search |
X-Recipient: | archive-cygwin AT delorie DOT com |
DomainKey-Signature: | a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id |
:list-unsubscribe:list-subscribe:list-archive:list-post | |
:list-help:sender:mime-version:in-reply-to:references:date | |
:message-id:subject:from:to:content-type | |
:content-transfer-encoding; q=dns; s=default; b=SHAll3Sjn+gjz9eb | |
xHA45o9uIiMokkZftaeu8/uI7jyR9RJ6uY0zUl/3OgvuFi1dpm2vSs/9pX+XaUX1 | |
Spva5LRbshChZfP4CYkWXMFa8QKc8Z+/fPTO6VjgBi0O+U1qu/hhaLo2n8OXj5vB | |
6xHub7PooUlL0pE/sxerfvi976E= | |
DKIM-Signature: | v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id |
:list-unsubscribe:list-subscribe:list-archive:list-post | |
:list-help:sender:mime-version:in-reply-to:references:date | |
:message-id:subject:from:to:content-type | |
:content-transfer-encoding; s=default; bh=VnTEU0dRz4WsC4aVO9q3wh | |
K1j3I=; b=eB1XTZgIKx7VrlhuJ615b1bhJZ34yrxyM5xuR8zTH8TACxztdq1Frp | |
merL5pw4jv8Ki3DsD5o/r9T9K1Oj3osMuHjRBRTIr/dadGH43saYvBnWu5rUDe3z | |
/h4kljWhAHEEALmchaeT4NhGBKC39xmhUb3Sz25fCsQFEJ/duLjfg= | |
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm |
List-Id: | <cygwin.cygwin.com> |
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com> |
List-Archive: | <http://sourceware.org/ml/cygwin/> |
List-Post: | <mailto:cygwin AT cygwin DOT com> |
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs> |
Sender: | cygwin-owner AT cygwin DOT com |
Mail-Followup-To: | cygwin AT cygwin DOT com |
Delivered-To: | mailing list cygwin AT cygwin DOT com |
Authentication-Results: | sourceware.org; auth=none |
X-Virus-Found: | No |
X-Spam-SWARE-Status: | No, score=2.3 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 |
X-HELO: | mail-qk0-f178.google.com |
MIME-Version: | 1.0 |
X-Received: | by 10.140.148.67 with SMTP id 64mr36297173qhu.74.1436548562891; Fri, 10 Jul 2015 10:16:02 -0700 (PDT) |
In-Reply-To: | <5C24455B-3D28-4C6D-A77B-70BB5D67F0AA@etr-usa.com> |
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> |
Date: | Fri, 10 Jul 2015 11:16:02 -0600 |
Message-ID: | <CANnLRdhZvS6AopLcoB=MTgMCDwq_znmsZNARP1LnKaKufoHUbw@mail.gmail.com> |
Subject: | Re: Telnet / SSH connection timeout on LAN |
From: | Stephen John Smoogen <smooge AT gmail DOT com> |
To: | cygwin AT cygwin DOT com |
X-IsSubscribed: | yes |
X-MIME-Autoconverted: | from quoted-printable to 8bit by delorie.com id t6AHGIFT006704 |
On 10 July 2015 at 07:19, Warren Young <wyml AT etr-usa DOT com> wrote: > On Jul 9, 2015, at 12:04 AM, Andrey Repin <anrdaemon AT yandex DOT 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
webmaster | delorie software privacy |
Copyright 2019 by DJ Delorie | Updated Jul 2019 |