Submission for comp-unix-microport

[UNIX-UNIX Cp]

Path: tolerant!voder!apple!rutgers!ucsd!ames!killer!texbell!splut!jay
From: jay at splut.UUCP (Jay "you ignorant splut!" Maynard)
Newsgroups: comp.unix.microport
Subject: Re: How does Microport System V/AT handle bad blocks?
Message-ID: <798 at splut.UUCP>
Date: 1 Jan 89 22:11:40 GMT
References: <460 at tarpit.UUCP> <326 at focsys.UUCP> <464 at tarpit.UUCP> <2689 at nuchat.UUCP> <211 at trevan.UUCP>
Reply-To: jay at splut.UUCP (Jay "you ignorant splut!" Maynard)
Organization: Confederate Microsystems, League City, TX
Lines: 58

In article <211 at trevan.UUCP> trevor at trevan.UUCP (trevor) writes:
>Well well I spent a whole week trying to sort my disks out and now it
>turns out to be FSCK to be at fault. Microport does admit to there being
>a problem but it says only with file systems greater tan 130000 blocks.
>All my file systems are less than 100,000 blocks and I still get this
>problem.

I first encountered this problem on an 84K block filesystem. I spent a
week with fsdb and fsck, using fsdb to straighten out the worst
problems, and then using fsck to (I thought) straighten out the
filesystem. ARGH!! I finally gave up when Steve told me about the bug.

>I must thank Steve for a workaround which will help but there is still
>the problem of the file system check at boot up. I guess we will have to make
>it interactive inorder to stop this self destruction. This means that
>unattended reboots after powercuts etc, will not be possible unless
>someone can tell us how to prevent fsck from rebuilding the free list
>first time round. I guess it might be possible to create some sort of
>shell programm to interact with fsck and answer all the questions.

I've already done this in response to this problem.
To turn off the automatic fscks at boot time, edit /etc/bcheckrc and
/etc/mountall and remove the -y switch from the fsck command.
I now leave a boot floppy in drive 0 with the door closed, so that in
the event of an automatic reboot, it doesn't even attempt to reboot the
full system; I then manually fsck things from the boot floppy, doing it
twice if the first time claims that the free list needs rebuilding.
This makes it even more important to have at least one partition small
enough to be checked without the need of a work file; fsck that one
first, then mount it on /mnt and use /mnt/foo as the work file for the
rest of them.

>This must be the worst bug in Microports system and is worse than most
>viruses. Why didnt Microport warn us of this problem? If they knew
>about it I think it was totally negligent of them not to have told us.

They didn't know it was fsck causing the problem until Steve took one of
their service techs through crashing a large file system and showed him
how fsck would corrupt it. This only happened a couple of months ago.

As for telling us about known bugs, they only do that for holders of
their misnamed support contracts. I agree that it's negligent for them
not to periodically mail out lists of known bugs. Maybe they're afraid
it'll make their software look buggy.

Actually, it's not that bad of a bug; if you know about the workaround,
it's easy (though time-consuming) to deal with. It'd not be a nuisance
at all if the system didn't repeatedly crash.

>I think that Microport should make the fixing of this bug their top priority.

What? Service their customer base? Radical concept, that.

-- 
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
uucp:       uunet!nuchat!    (eieio)| adequately be explained by stupidity.
   hoptoad!academ!uhnix1!splut!jay  +----------------------------------------
{killer,bellcore}!tness1!           | Free Texas from its chains: SECEDE!!