How does Microport System V/AT handle bad blocks?

[trevor]

In article <2689 at nuchat.UUCP>, steve at nuchat.UUCP (Steve Nuchia) writes:
> 
> The problem here is a BUG in FSCK.  There is a workaround.  I know
> of at least two people in Microport who have been assigned to fix
> it, I don't know if either of them made any more progress than I did.
> 
> The bug is that, for large filesystems, fsck's free block bitmap
> gets corrupted.  The bitmap is built in phase 1, corrupted in phase 2
>.....
> 
> The workaround is to run fsck on your filesystem but NOT ALLOW it
> to REBUILD THE FREELIST.  Then run fsck -f on it.  The -f option
> says to just run phase 1 and 5/6, and it can be allowed to rebuild
> the freelist since it didn't scribble on its bitmap in phase 2.
> 

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 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.

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.

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