Date: Sat, 04 Sep 1999 11:58:24 -0500 From: "Jeffrey J. Mountin" <jeff@mountin.net> To: John Polstra <jdp@polstra.com> Cc: stable@freebsd.org Subject: Re: buildword curiousities Message-ID: <3.0.3.32.19990904115824.01512db0@207.227.119.2> In-Reply-To: <199909040107.SAA10009@vashon.polstra.com> References: <3.0.3.32.19990903155015.0142d100@207.227.119.2> <3.0.3.32.19990903155015.0142d100@207.227.119.2>
next in thread | previous in thread | raw e-mail | index | archive | help
At 06:07 PM 9/3/99 -0700, John Polstra wrote: >Hmm, when you suspect problems on a CVSup server, you can do us all a >big favor by writing to the site's maintainer and asking him to check >and make sure things are running smoothly. The maintainers are listed >along with all the CVSup mirror sites in section 25.4 of the FreeBSD >Handbook. I am aware of this, but it's 17 hops over to cvsup6, 15 to cvsup2 and cvsup3, 19 to cvsup5, which have become a bit crowded the past month of so and cvsup5 was not listed when I last checked. With bbnplanet (and AT&T) in the path *and* since it happens during day mostly I'd rather think it's a network hiccup. >I'm the maintainer of cvsup6, so consider me contacted. :-) I checked >the log files and couldn't find any sign of trouble. It seems to be >ticking along nicely. Perhaps your network path to cvsup6 is bad >lately. Try a couple other mirror sites and see if any of them work >better for you. (Just add "-h cvsup5.freebsd.org" to your cvsup >command line to try cvsup5, for example.) <g> Usually at this point when I try the others, it's not possible to connect immediately and after 3 - 5 minute timeouts a break is in order. 8-/ >The next time you get one of those hangs on cvsup6, please leave it >hung and drop me an e-mail. If I'm around at the time, I'll login to >cvsup6 and see what your connection looks like from its end of the >pipe. Will do. My connection has a 4 hour session limit, so I include the time left for the connection and keep it live, as well as more follow-up checking on the network path. >If it is then it's a problem with your network stack probably. Try >multiplexed mode (the default in CVSup-16.0, which I see you're >using). It's the best all-around mode to use, and it should work in >all situations. I'll change to '-P m' then. >It shouldn't. CVSup is carefully designed to do all its work in >temporary files, renaming each one atomically to the actual name only >after it has confirmed that the MD5 checksum is correct. At worst you >might end up with a few stray temporary files lying around. But it >tries hard to clean those up as well, even if you kill it with ^C. Where does it store the temp files? Memory? Don't recall seeing any and don't have the source (only thing I don't compile). >From time to time I receive reports of mangled files. But they >always (always, always, every time) have turned out to be caused by >HW problems or kernel problems. You can tell by making a hex dump of >the offending file with "hd", and looking at where the damage begins. >I can almost guarantee that it will begin at an offset which is a >multiple of 4K bytes (usually it's a multiple of 8K bytes). That's >a dead giveaway that the VM system or your hardware has screwed you. >There's nothing CVSup or any other program can do to protect you >against that. If the MD5 checksum says the file is fine (when it is >still in the kernel buffers, no doubt) but then the kernel and HW >don't manage to get the bits written correctly onto the disk -- well, >the application did its best. Next time it happens I'll track down the offending file and check, but the last time the corrupted file was installed from CD and survived many builds. Could be a drive issue, however. One more thing to watch closer. thanks Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.3.32.19990904115824.01512db0>