From owner-freebsd-hackers Sat Dec 24 02:46:57 1994 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id CAA25160 for hackers-outgoing; Sat, 24 Dec 1994 02:46:57 -0800 Received: from physics.su.OZ.AU (dawes@physics.su.OZ.AU [129.78.129.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id KAA25154 for ; Sat, 24 Dec 1994 10:46:55 GMT Received: by physics.su.OZ.AU id AA20091 (5.67b/IDA-1.4.4 for freebsd-hackers@freebsd.org); Sat, 24 Dec 1994 21:44:50 +1100 From: David Dawes Message-Id: <199412241044.AA20091@physics.su.OZ.AU> Subject: Re: A lighter sup -v? To: mark@grondar.za (Mark Murray) Date: Sat, 24 Dec 1994 21:44:49 +1100 (EST) Cc: dawes@physics.su.oz.au, jkh@time.cdrom.com, mdavis@io.cts.com, freebsd-hackers@freebsd.org, mark@grunt.grondar.za In-Reply-To: <199412240642.IAA01245@grunt.grondar.za> from "Mark Murray" at Dec 24, 94 08:42:36 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1548 Sender: hackers-owner@freebsd.org Precedence: bulk >> >No, actually not. It means "I checked the file and the dates didn't >> >match, even if the contents did, so I'm stamping it again and >> >recording the fact in my sup logs." In most stable situations, you >> >shouldn't even see that most of the time! >> >> It means that the ctime of the file is more recent that the previous >> sup date, but the mtimes are the same. The actual file contents (and >> file size) are not checked. A common cause of these updates is if the >> sup server's collection has been restored from a backup, or moved to a >> different filesystem, etc. > >BIG bummer, this. Since freefall's disk bounced, I have been >_continuously_ supping. 95% Of this was "updating". Time now for SUP2? >(I am in South Africa, and my link to the Internet is a 2-wire leased >line with 14400 baud modems - ok for general work, LOUSY for bulk >movements) I made some changes to sup (for our local XFree86 use) which add an option to avoid updates for regular files when the stat information available at the scan phase (just the mode) matches. We use sup to keep our two main servers in sync, and we sometimes sup in both directions (yes, this has to be done with care). Doing this was completely impractical (read: took forever) without an option to avoid updates. The slowness of the update process over a slow link is I think mostly due to the two-way nature of the traffic (client requests stat info for first file, server sends it, client requests stat info for second file, ...) rather than the quantity of traffic. David