Endless bummer...

[was-John McMillan]

In article <802 at bagend.UUCP> jan at bagend.UUCP (Jan Isley) writes:
>In article <9832 at csli.Stanford.EDU> crimmins at csli.stanford.edu (Mark Crimmins) writes:
>>This has happened to me a couple of times, and I wonder if anyone
>>knows why.  I turn on my 3b1 (3.5M 67HD rev. 3.5 sys and utils) and it
>>goes through the normal boot procedure until the "checking stored
>>files" screen turns to gibberish and then the boot procedure starts
		^^^^^^^^^^^^^^^^^^
>>over (and over and over).  The problem goes away when I "upgrade" all
>>system files from floppy, including utilities.
:
>FSCK has a nasty habbit of saying it fixed a problem it found in the file
			    ^^^^^^^^^^^^^^^
>system when it really did not fix it.  You know it found a problem if the
>system does a reboot after the "checking stored files" routine.  Usually
>the system will come up after the second time through.  But, sometimes
>the problem was not really fixed, and fsck will *never* be able to fix
>it on a mounted file system.
:

Maybe someone has clarified this by now.  (Or maybe I'm missing the
exact scenario: I get lost in the technical jargon of "turns to gibberish".)
(Well, I guess I understand that term regarding a friend's daughter....)

Occsionally, you get folks who miss the point that you can fool the
File System some of the time -- but not ALL of the time:
      +	WRITING A FILE uses/consumes/alters the File System FREE-LIST.
      +	FSCK (often) re-writes the File System FREE-LIST.
    Ergo:
      +	It's a less than brilliant move to have FSCK write a log FILE
		on the File System it's manipulating -- this intrinsically
		attempts to alter the very data fsck's correcting.
    Example:
      + If the Free List is corrupted -- perhaps it was even the CAUSE
		of the crash -- the FSCK log file is building an INODE
		(file) using that corrupted data, and building it in
		RAM while the DISK is being fixed.  Then it gets moved
		to the disk....
      + Or, maybe, that INODE is written to disk, but the Superblock,
		as created by FSCK, still marks some of those now-used
		blocks as FREE....  Time for "Duplicate BLOCKS"
		(or whatever).

I DON'T know of any FSCK errors -- FSCK probably DOES correct the problems.
But SOMEONE wrote an RC script that corrupts the data AS IT IS BEING
CORRECTED.  This has been discussed, here, many times.  It will be discussed
many more.  I have requested this be fixed w/in AT&T sources.

	The only correction is to ELIMINATE any saving of FSCK
	output IN A FILE on the same FS being checked.  Period.

So far, I trust FSCK far more than most C programmers I know !-)

john mcmillan	-- att!mtunb!jcm