rwl@uvacs.cs.virginia.edu (Ray Lubinsky) (02/22/89)
Has any one experienced a SunOS 4.0 system in which the file systems are periodically trashed (lots of files removed by fsck with UNKNOWN FILE TYPE)? I just reformatted and reloaded the system and user files yesterday and today, not 24 hours afterward, "fsck -n" reports dozens of UNKNOWN FILE TYPEs on disk 0 and several in /var mounted on the A partition of disk 1. I think it's a hardware problem, but the Sun engineer who came out and checked board settings and voltages says the system's clean. Though I've not been getting any messages from the disk controller reporting bad I/O, I'm still convinced it's a hardware problem. For one thing, it was running fine for three months and then it started becoming crippled by UNKNOWN FILE TYPEs. Frequently these are crucial programs or data, but often they are files which are never touched (like some of the stuff in /usr/lib/adb); in either case, the machine won't autoboot because it needs human permission to blow away the bad files. Here are my stats: Sun 3/260 (two Fujitsu-M2333 drives with Xylogics 451 controller) serving fifteen diskless 3/50's and two diskful 3/60's on a local thinwire Ethernet hanging off of ie0. One of the 3/60's is running SunOS 3.3 and everything else is running SunOS 4.0 (GENERIC kernels). The server gateways to the building Ethernet via ie1; it and the rest of the machines remote-mount local (UVa) software directories from a 3/260 running SunOS 3.3. Does any of this sound familiar to anyone? Perhaps a marginal disk controller? I'm certainly willing to be wrong about the origin of the problem, but because these problems have only recently cropped up, I can't imagine a software origin to the problem. Thanks to any and all who might have a pointer or two! Ray Lubinsky rwl@trinity.cs.virginia.edu (Internet) rwl@virginia (BITnet) Department of Computer Science, ...!uunet!virginia!uvacs!rwl (UUCP) University of Virginia (804) 979-6188 (voice)
rwl@uvacs.cs.virginia.edu (Ray Lubinsky) (03/09/89)
Thanks to all on this list (and on Sun-Nets to which I erroneously posted this query), but we've solved the problem with this. Swapping in a new CPU card did the trick. My guess would be bad address translations were being performed by the MMU. Ray Lubinsky rwl@trinity.cs.virginia.edu (Internet) rwl@virginia (BITnet) Department of Computer Science, ...!uunet!virginia!uvacs!rwl (UUCP) University of Virginia (804) 979-6188 (voice)