input/output error on hd
Marty Landman
martster at gmail.com
Tue Feb 27 22:13:08 UTC 2007
On 2/26/07, Jerry McAllister <jerrymc at msu.edu> wrote:
>
> On Mon, Feb 26, 2007 at 04:49:46PM +1100, Ian Smith wrote:
> >
> > Firstly, Marty, you should run dumpfs(8) on your ad1s1a.
Well this didn't raise my spirits too much:
%sudo dumpfs /dev/ad1s1a
dumpfs: /dev/ad1s1a: could not read superblock to fill out disk
%
So I can get to all but my "dead" blocks via the DD command and work with
it in hex; used to do mainframe assembler programming and don't particularly
mind the workout, so to speak.
Only with a road map it's not possible. Maybe I should write Ian Dowse and
see if he can point me in the right direction (pun intended).
Marty :--\
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
> >
>
--
Web Installed Formmail - http://face2interface.com/formINSTal/
Webmaster's BBS - http://bbs.face2interface.com/
More information about the freebsd-questions
mailing list