Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!ncar!ames!xanth!nic.MR.NET!shamash!com50!kksys!gk
From: gk@kksys.mn.org (Greg Kemnitz)
Newsgroups: comp.unix.microport
Subject: Re: How does Microport System V/AT handle bad blocks?
Message-ID: <920@kksys.mn.org>
Date: 28 Jan 89 03:52:43 GMT
References: <460@tarpit.UUCP> <326@focsys.UUCP> <464@tarpit.UUCP> <2689@nuchat.UUCP> <211@trevan.UUCP> <798@splut.UUCP>
Reply-To: gk@kksys.UUCP (Greg Kemnitz)
Organization: K and K Systems, Minneapolis MN
Lines: 28

In article <798@splut.UUCP> jay@splut.UUCP (Jay Maynard) writes:
>In article <211@trevan.UUCP> trevor@trevan.UUCP (trevor) writes:
        [ comments about Microport fsck trashing disks...]
>>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.

Actually, they have been aware of it for much longer than that... Well
over a year ago we were experiencing the same problem and had MANY
long discussions with them regarding it.  They informed us that there
was a known problem with fsck, and that "someone is working on it".
This was with the 1.3.6 release.  As of the 2.2 release it still was
not fixed.

We did discover a workaround though...  Replace the system with a '386
running Interactive 386/ix.  Works great!  Also fixes all the other
problems that Microport is "working on".

Of course, this "solution" IS a bit expensive....

Greg Kemnitz / K and K Systems / PO Box 41804 / Plymouth, MN 55441-0804
Domain:  gk@kksys.mn.org  /  UUCP:  ...!rutgers!bungia!kksys!gk
Voice:   (612)475-1527    /  Fax:   (612)475-1979