input/output error on hd

Jerry McAllister jerrymc at msu.edu
Mon Feb 26 15:39:25 UTC 2007


On Mon, Feb 26, 2007 at 04:49:46PM +1100, Ian Smith wrote:

> On Sun, 25 Feb 2007, Jerry McAllister wrote:
>  > On Sun, Feb 25, 2007 at 10:38:01AM -0500, Marty Landman wrote:
>  > 
>  > > On 2/24/07, Jerry McAllister <jerrymc at msu.edu> wrote:
>  > > >
>  > > >
>  > > >Well, I think you are past any label problems now and on to the
>  > > >bad sectors and/or finding superbocks.    Although I am not quite clear
>  > > >from above what resulted in the 'INCOMPLETE LABEL...'  message.
>  > > 
>  > > 
>  > > Ok then, can you point me to somewhere that can learn about superblocks and
>  > > give me an idea of what to do next? 
>  > 
>  > Most of what I figured out several years ago (and have essentially
>  > forgotten since) came from the handbook and something I found by
>  > searching the web that gave the layout of blocks and chains.  I would
>  > have to go back searching again.
> 
> Failing someone who actually knows what they're talking about re UFS
> structures chipping in to this discussion, all I can offer in addition
> is what my own exploration of manuals and a bit of googling turned up .. 
> 
> Firstly, Marty, you should run dumpfs(8) on your ad1s1a.  With the -m
> switch, this produces a single line suitable for feeding into newfs with
> all parameters, and is probably worth saving for all slices in case of
> any subsequent emergencies.  I've just done that for mine, anyway, along
> with fdisk and boot0cfg -v output, and bsdlabel output for UFS slices. 

Yes.  Good call.
I couldn't think of the dumpfs command the other evening when
I was writing, but that is the place to start.   Definitely run
that output to a file.   It will take some learning to understand
how to follow it out.   There are tables somewhere that tell what
each of those things mean and what fields to look in in the raw
data to find each thing - and to write it back if that is what you
will want to do.

Note that it will tell you in the first line if your filesystem if UFS2
or something else.

Good luck - maybe if you are successful, you can write a paper on it
and post it to a web page somewhere.   I probably should have way back
when and then I would remember more now.

////jerry

> 
> Without the -m switch, feed the output to a file, or less, as it's very
> voluminous.  For a 240GB drive, it'll likely be huge.  However the data
> at the head is probably what's needed, though I can't make much of it.
> 
> This post by Ian Dowse explains how to compute where the superblocks
> are, for a quoted example dumpfs: http://noc.caravan.ru/faq/SBLOCK.html
> 
> Note however that Ian is talking about UFS1 (where the superblock offset
> was 32) but if you consult fsck_ffs(8) you'll see (under -b) that for
> UFS2, which you almost certainly would have used, it's at 140 .. I
> gather that's the offset from the start of each cylinder group?
> 
> 
>  > >   Also assuming my bad sectors really are
>  > > totally bad, wouldn't fsck allow me to mark them as unusable and move on?
>  > 
>  > No, fsck does not do that.   Marking blocks bad happend below the
>  > level of the OS - generally in the disk controller itself.   It remaps
>  > sectors until it runs out of spares and when it runs out, it starts
>  > reporting unrecoverable errors.   This is not even reported to the OS
>  > until it runs out of spares.
>  > 
>  > The only thing you can do with those bad sectors is to try and figure 
>  > out if any of them are superblocks.  If they are, you can probably
>  > rebuild it from other superblock clones.   If it is not, it is probably
>  > lost data.  In that case try to overwrite the bad sector.  If that 
>  > works, then the sector itself is OK, but the data that was there is
>  > gone.   If it doesn't work, then it is bad and there is a good chance
>  > that more than data got nuked in the power failure - eg, it damaged
>  > the disk or controller in some way.
> 
> Seeing if fsck_ffs will use any discovered alternate superblocks would
> be the first step, and if so, whether that helps to get it mounted.  I'd
> certainly be careful to mount it read-only before trying data recovery! 
> 
> Since Marty has already been bravely using dd :) rewriting those sectors
> should be easy enough, bearing in mind the apparent off-by-one numbering
> difference between the sectors dd found bad and those fsck reported bad.
> 
>  > But, the next thing seems to be learning about how to follow the file
>  > chains and how to find and read and write superblocks.  Alternatively
>  > you can decide it isn't worth the effort to recover and try and write
>  > over the drive completely - just totally trash it - and see if those
>  > bad sectors will write.  If you did that, then you would have to rebuild 
>  > the slice and partition table and do a newfs before you could again
>  > use the drive and everything previously on it would be lost.
> 
> Well if a dd rewriting those specific contiguous sectors failed, I doubt
> that newfs would do any better, so the dd is definitely worth a try, but
> I wouldn't write anything further to the fs until all else has failed.
> 
>  > Good luck.
> 
> I can only echo that, again.
> 
>  > Maybe someone who has some experience in tracking file chains can
>  > respond and give you more helpp than can I.
> 
> Ditto for that .. I'm now very thoroughly out of my depth here, though
> I've learned a few new things through the exercise. 
> 
> Maybe mailing Ian Dowse with circumstances and the dumpfs head might be
> worth a try, Marty?  See the website committers' page for his address.
> 
> Cheers, Ian
> 


More information about the freebsd-questions mailing list