Date: Sat, 24 Dec 1994 21:44:49 +1100 (EST) From: David Dawes <dawes@physics.su.oz.au> To: mark@grondar.za (Mark Murray) Cc: dawes@physics.su.oz.au, jkh@time.cdrom.com, mdavis@io.cts.com, freebsd-hackers@freebsd.org, mark@grunt.grondar.za Subject: Re: A lighter sup -v? Message-ID: <199412241044.AA20091@physics.su.OZ.AU> In-Reply-To: <199412240642.IAA01245@grunt.grondar.za> from "Mark Murray" at Dec 24, 94 08:42:36 am
next in thread | previous in thread | raw e-mail | index | archive | help
>> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199412241044.AA20091>