Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!husc6!rice!sun-spots-request
From: rwl@uvacs.cs.virginia.edu (Ray Lubinsky)
Newsgroups: comp.sys.sun
Subject: My 3/280 is trashing its file systems
Message-ID: <2982@uvacs.cs.Virginia.EDU>
Date: 22 Feb 89 15:40:47 GMT
Sender: usenet@rice.edu
Organization: U.Va. CS Department, Charlottesville, VA
Lines: 37
Approved: Sun-Spots@rice.edu
Original-Date: 15 Feb 89 22:08:42 GMT
X-Sun-Spots-Digest: Volume 7, Issue 165, message 8 of 15

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)