Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!asuvax!anasaz!duane
From: duane@anasaz.UUCP (Duane Morse)
Newsgroups: comp.unix.wizards
Subject: Re: fsck fails...help!
Summary: May have to reformat
Keywords: fsck
Message-ID: <726@anasaz.UUCP>
Date: 15 Sep 89 19:30:12 GMT
References: <9171@pyr.gatech.EDU>
Organization: Anasazi Inc., Phoenix AZ
Lines: 35

In article <9171@pyr.gatech.EDU>, david@pyr.gatech.EDU (David Brown) writes:
> 
> Help!!  Fsck is failing on my machine.  I get the following error:
> 
> CANNOT READ: BLK 16 (CONTINUE)
> 
> In my trusty 4.3BSD System Managers Manual, I find that "...This
> should never happen.  See a guru."  Well, where better to find them
> than comp.unix.wizards?
> 
> Is the disk history?  Any help would be greatly appreciated.

The message means that it cannot physically read the block. I don't
know how fsck varies from one system to the next, but the version on our
NCR Tower 32/600 also stops when this happens.

The only time this occurred on our system, I made a lucky guess about
something and 'fixed' the problem. In particular, I determined which
physical blocks the message referred to, verified the problem by trying
to dd the block, and then, as root, wrote zeroes to the bad block. My guess
was that either the smart SMD controller would allocate an alternate
block when I tried to write to the bad one, or the sector/block
checksum was bad and writing to the block would put out a good checksum.
After this I could run fsck.

Even if this works in your case, you'll probably lose some important
files since block 16 is near the beginning of the inode list.
(They'll hopefully show up in lost+found.) The
alternative may be reformatting the disk and re-installing everything,
however, because I'm somewhat doubtful about Unix's alternate block
mapping (through software) when it comes to inode blocks.
-- 

Duane Morse	...{asuvax or mcdphx}!anasaz!duane
(602) 861-7609