Path: utzoo!attcan!uunet!lll-winken!ames!sun-barr!texsun!texbell!vector!killer!mjbtn!root
From: root@mjbtn.MFEE.TN.US (Mark J. Bailey)
Newsgroups: comp.unix.xenix
Subject: Re: Help! My fsck is broke
Summary: It has something to with LINK COUNT TABLE OVERFLOW
Message-ID: <478@mjbtn.MFEE.TN.US>
Date: 12 May 89 02:41:08 GMT
References: <1078@cs.rit.edu> <897@impch.UUCP>
Organization: JobSoft Design & Development, Murfreesboro, TN
Lines: 57

In article <897@impch.UUCP>, patg@impch.UUCP (Patrick Guelat) writes:
> In article <1078@cs.rit.edu> exg9537%ucss@cs.rit.edu () writes:
> +--------------
> | At work we are switching over to an intel 386 running SCO 2.3.1.
> | [....]
> | When using fsck on the root system it starts out fine:        
> | /dev/root:
> | 
> | ** Phase 1 - Checking Blocks and ...
> | 
> | but after about a minute the prompt comes back.  No error messages, and
> | never entered Phase 2.  I have tried most every fsck option.  No help.
> +----------------
> OOOPS ! We had the same problem a few weeks ago ! I've tried fsck about
> one hundred times and I never saw more than Phase 1 !! It seems, that
> it breaks down, must be a really nasty bug. Our solution was to take
> an old fsck from a Xenix 2.2.1 286 system and that one worked...
> After that, 'fsck -s' with the new fsck didn't break anymore...
> 

I just had the same problem too.  A long newsfeed the other night (6 hours
on a telebit tb+ (yipes!!!) took 14 hours to uncompress on my 80386, sco
2.3 system !!!  Something was wrong.  At any length, it ran out of space
during the operation and I began to notice the whole system really running
sluggishly.  I then did an 'fsck -s -rr /dev/root' and got the very same
halt after Phase 1.  A client of mine is running 2.2.4 on an 80386 and I
got that fsck as per the above discussion, and got it to run, but I got

LINK COUNT TABLE OVERFLOW
Continue?

and it always answered 'yes' due to the -rr.  Well, I ran it once and then
tried my 2.3 fsck to see if it would work.  No go.  I ran the 2.2.4 fsck 
again and still got the above message, only this time when it was done, it
only had to patch up 41 bad inode counts instead of the first time's 62.
The above message means that an internal table for fsck that contains allocated
i-nodes with a link count of 0 has run out of space (this from the manual), 
and I assumed that each time, it processed what it could fit in the table
and the rest were ignored (as per the above messages).  I therefore ran it
several times and it got them all taken care of.  I then ran the 2.3 fsck and
it ran fine now.

It appears that where the 2.2.4 fsck can detect the LINK COUNT TABLE being
filled up and opt you to continue on anyway to process what you have got, the
2.3 fsck either doesn't support that, or is *supposed* to, but is buggy.

Any comments SCO?

Mark.


-- 
Mark J. Bailey                                    "Ya'll com bak naw, ya hear!"
USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 ___________________________
VOICE:  +1 615 893 0098                            |         JobSoft
UUCP:   ...!{ames,mit-eddie}!killer!mjbtn!mjb      | Design & Development Co.
DOMAIN: mjb@mjbtn.MFEE.TN.US                       |  Murfreesboro, TN  USA