[comp.unix.wizards] bad bitmaps that fsck can't seem to fix

whm@arizona.edu (Bill Mitchell) (07/23/87)

One of our 785s running 4.3+NFS has a couple of filesystems that when checked,
produce the message "BLK(S) MISSING IN BIT MAPS". fsck claims to "salvage"
the bit maps, but a subsequent run of fsck produces the same diagnostic.

Running icheck on these filesystems produces several messages of the form:

<blkno> dup frag; inode=0, class=free frag

Anybody encountered this problem before?  Know how to fix it?

BTW-The disks in question are RA81s on a UDA-50; we're running the stock
4.3+NFS uda driver.

					Bill Mitchell
					whm@arizona.edu
					{allegra,cmcl2,ihnp4,noao}!arizona!whm

whm@arizona.edu (Bill Mitchell) (07/24/87)

In article <1825@megaron.arizona.edu> I wrote:
> One of our 785s running 4.3+NFS has a couple of filesystems that when checked,
> produce the message "BLK(S) MISSING IN BIT MAPS". fsck claims to "salvage"
> the bit maps, but a subsequent run of fsck produces the same diagnostic.
> 
> Running icheck on these filesystems produces several messages of the form:
> 
> <blkno> dup frag; inode=0, class=free frag
>
> ...

We noticed that while running fsck we'd frequently get a soft ecc on one of
the memory controllers.  We took out that controller and now fsck and icheck
pronounce those filesystems as being ok. (!)

					Bill Mitchell
					whm@arizona.edu
					{allegra,cmcl2,ihnp4,noao}!arizona!whm