On Thu, 21 Aug 2003, Peter Peltonen wrote: > On Tue, Aug 19, 2003 at 08:20:53AM -0400, Robert G. Brown wrote: > > I do have one last suggestion, though. rsync documents that the -vvv, > > -vvvv and higher options are only "useful for debugging rsync". That is > > usually a diplomatic way of saying that they will flood you with detail > > Okay, output from -vvv for my RH62 updates can be browsed at > > http://www.iki.fi/peter.peltonen/linux/thu2.txt > > -vvvv produced 17 megs of info, so it's only available on request :) It looks like the non-up-to-date files do not have the same checksums. This leads to all sorts of interesting speculations, but it also points to all sorts of useful flags to use for testing. Read man rsync, but hop from each occurrence of the word "checksum" to the next. You can learn a lot about how rsync determines file identity (on the basis of a mix of timestamp and checksum, apparently) and at least try some various alternative sets of flags designed to force or prevent the use of checksums or control just how they work. I'd also recommend doing the rsync for a much smaller subset of the files than the whole thing, or even several disjoint subsets, so that you don't have to wait a full day for the next round of results. Offhand it looks like the problem is likely associated with the incorrect (non) usage of the -t flag, OR as I've repeatedly pointed out, perhaps they are doing something odd on the server side that is causing a time/size or checksum test to fail. Perhaps they have disabled checksums in some way because it is expensive in server CPU and they appear to be very load sensitive. Perhaps they have precalculated them somehow but have failed to update them on part of the 6.2 tree. I don't know and don't know how to find out other than asking the server humans for help. Note that there IS an option that will almost certainly "work" to surpress this unwanted file transfer. The --size-only flag tells rsync to ignore checksums and use only the size of the file to decide whether or not to transfer. Given that the file size is NOT changing, I don't see how this could fail to prevent transfers. Speaking of which, is ANYBODY still maintaining 6.2? I think not. I think you are perfectly safe freezing the entire distribution and just running from your internal image, unless you have some evidence that somebody is still actually rebuilding and updating 6.2 RPMs and dropping them onto the repository you're using. I don't think that somebody includes Red Hat or the kernel people -- they typically keep a release up only through one major number update or at most two. When was the last time a file in the repository really changed? --size-only might reduce the noise and let you find out. Obviously you know that unless your organization relies on a binary that cannot be rebuilt and only runs on 6.2 libraries or has some very old machines that one cannot reasonably upgrade to run a more recent version, everything else in 6.2 is a potential security problem, a performance problem, cheats yourself and users out of the latest advances in the entire software collection, and more. RH is up to 9, right, so it seems way past time to abandon 6. 9 is stable and feature rich. rgb -- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
