Extreme unhappiness caused by gtar on AT&T 3B1 v3.51

Chris Lewis clewis at ferret.ocunix.on.ca
Sat Apr 27 11:39:50 AEST 1991


In article <1991Apr24.201757.26147 at cbnewsj.att.com> dwex%mtgzfs3 at mtgzy.att.com (David E Wexelblat) writes:
>[gtar v1.09, compiled basically as System V, with 3B1 shared libraries]

He goes on to describe how some testing with gtar managed to splatter
his hard disk.

I've had similar things happen twice, once while running something like:

	find <some dir> -name '*.Z' exec compress -dc '{}' ';' | 
	    grep '^Subject:' | sed ...
	
       (sort of like finding all of the subjects out of a compressed
       news spool - LOTS of files)

and the other time the machine was "dead in the morning".  Could have been
a compress(v4)/pathalias(v10) run.  Or B-news expire(2.11.19).

3.5.1.4 O/S, no hardware mods.  No disk errors in the log.

The first time just managed to nuke getty and init.  Easy to repair.

The second time nuked the /bin and /etc directory, and placed all of the
subfiles under /lost+found.  Repaired by remaking the directories (from the
boot floppy) and comparing checksums with similarly configured 3b1's to
figger out which /lost+found file was which.

[NOTE: there is enough room on the boot floppy to put fsck on it.  DO IT
NOW!  I had to wait for a courier...]

I figger that there is a very subtle bug down deep somewhere in the O/S
which causes F/S corruption in exceedingly rare high load situations.
(It could even be the infamous SV inode bug manifesting itself in a slightly
different way).  This doesn't seem related to the "pulse dial during high
disk load causing panic" problem which I've reported earlier, and has
completely disappeared since I went to tone dial.

Further, at least at my version level, the 3b1 is rather fragile in disk
full situations.  If your disk goes full, you can lose /etc/inittab,
/usr/lib/uucp/L.sys as well as other things (eg: setgetty edits /etc/inittab
on uucico outbound startup - if this occurs during disk full - poof!)
I suggest you copy some of these files somewhere so that you can recover...
-- 
Chris Lewis, Phone: (613) 832-0541, Domain: clewis at ferret.ocunix.on.ca
UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List:
ferret-request at eci386; Psroff (not Adobe Transcript) enquiries:
psroff-request at eci386 or Canada 416-832-0541.  Psroff 3.0 in c.s.u soon!



More information about the Comp.sys.3b1 mailing list