Subject: Re: sup problems?
To: NetBSD-current Discussion List <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 09/27/1999 16:56:53
[ On Monday, September 27, 1999 at 21:49:05 (+0200), Manuel Bouyer wrote: ]
> Subject: Re: sup problems?
> Actually I experimented a bit with this and never found a copy method which
> would keep sup from updating all files.
I thought I remembered someone having looked into this before....
It would seem to me that SUP is too aggressive with noticing inode ctime
on files -- though having an option to force copying if just the ctime
change is a good idea (eg. there could have been a real change in
attributes such as ownership or permissions that caused the file's ctime
to change), I don't think this should be the default behaivour,
especially when SUP is employed to simply mirror a source tree. For
directories, of course, this is an entirely different matter! ;-)
It would appear upon examination of its manual page that rsync only pays
attention to mtime by default, which seems to me to be a much better
default behaviour to emulate.
Of course why even SUP should take over 11 hours to transmit timestamps
for 46,657 files and the bodies of 39 files is beyond me! I don't know
exactly what's transmitted in the SUP protocol but taking a wild guess I
would say that were the data to be transmitted constantly over my
26.4kbps link then it should not have taken more than 2 hours. Perhaps
the SUP protocol is not windowed and requires handhakes for every file?
I know that rsync does seem faster than SUP and even though it does
cause a non-trivial load on the server perhaps SUP should be ditched by
NetBSD in favour of rsync. (Not that I would expect the server
directory trees to be copied around on a very regular basis!)
BTW, because of use of TCP_NODELAY in SSH, rsync over SSH makes such
effective use of the maximum bandwidth of a narrow bandwidth pipe that
it is literally impossible to get a TCP handshake to complete
successfully without first stopping or pausing the rsync and/or ssh
process! That would suggest to me that even alone rsync makes very good
use of all available bandwidth
Greg A. Woods
+1 416 218-0098 VE3TCP <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>