Date: Fri, 24 Jul 1998 22:36:16 -0700 From: John Polstra <jdp@polstra.com> To: mcdougall@ameritech.net Cc: current@FreeBSD.ORG Subject: Re: strange src tree corruption Message-ID: <199807250536.WAA06339@austin.polstra.com> In-Reply-To: <35B90D60.3FE563F0@ameritech.net> References: <35B90D60.3FE563F0@ameritech.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <35B90D60.3FE563F0@ameritech.net>, Adam McDougall <mcdougall@ameritech.net> wrote: > This seems to happen now a few times each time I attempt a buildworld, > the compile bombs out with something like this: > /asynch/src/gnu/usr.bin/perl/perl/perl.c:1478: unterminated string or > character constant/asynch/src/gnu/usr.bin/perl/perl/perl.c:1239: > possible real start of unterminated constant > /asynch/src/gnu/usr.bin/perl/perl/perl.c:1236: unterminated `#if' > conditional > /asynch/src/gnu/usr.bin/perl/perl/perl.c: In function `do_eval': > /asynch/src/gnu/usr.bin/perl/perl/perl.c:1236: parse error at end of > input/asynch/src/gnu/usr.bin/perl/perl/perl.c:118: warning: > `moreswitches' declared `static' but never defined > *** Error code 1 > > this is right after a cvsup. if I rm the file, and cvsup, its magically > fixed. <scratch head here> > The filesystem this partition is on has softupdates, but thats the only > thing special I can think about it. I recently copied my src tree off it > and newfs'ed but the problem remains. Is there something that may be > stopping cvsup from properly checking or updating corrupted files? This really sounds like hardware problems and/or filesystem damage. The next time it happens, look at the bad file with "hd". I bet you'll find that the corruption begins and ends exactly at a 4K boundary in your file (4K = 1 page). To understand CVSup's behavior in the presence of this kind of corruption, you have to realize two things. 1. CVSup first decides which files _might_ need updating, by examining the information it can get from a call to stat(2). This includes the modtime of the file and its size. If there's no difference between the stat() information on the client and on the server, then CVSup decides that the file is up to date. In that case, it never even opens the file, and it doesn't consider it any further. Unfortunately, the kind of corruption caused by filesystem damage or hardware problems often doesn't change the file's modtime or its size at all. Such corruption goes unnoticed by CVSup until the next time the file is changed on the server, which could be a very long time from now. Around this point in the lecture, a few people always pipe up and say, "That's too dangerous! It should MD5 each file every time you run it!" Nope, wrong answer. Try it some time. You _cannot_ achieve reasonable update performance if you do that. You _must_ cull out the unchanged files based on stat() information first. Also, c'mon -- it's unreasonable to expect a file update program to be robust in the face of hardware problems and/or filesystem damage. No program is robust under those conditions. 2. Whenever CVSup updates a file in any way, it computes the MD5 checksum of the updated file and checks it against the server's version of the file. So at the time CVSup writes the new file, it is certain that what it is writing it is correct. BUT as an application program, it can only check the data that it sends to the write() system call. In a flakey system, a lot can happen to that data before it gets physically written to the disk drive. Believe me, I've seen it all. I've seen 1-bit errors in files, and I've seen page-size blocks of zeros or page-size chunks of completely unrelated files splatted into the middle of other files. There's no way for CVSup to check for that kind of damage. Even if it re-opened the file and read it back again, the data would most likely come out of the kernel's buffer cache, which still wouldn't reflect what was actually on the disk. So: suspect your hardware, and suspect soft-updates. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807250536.WAA06339>