Re: input/output error on hd

On Sun, Feb 25, 2007 at 10:38:01AM -0500, Marty Landman
wrote:

> On 2/24/07, Jerry McAllister <jerrymcmsu.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.

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

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.

Good luck.

Maybe someone who has some experience in tracking file
chains can
respond and give you more helpp than can I.

////jerry



> 
> Marty
> 
> -- 
> Web Installed Formmail - http://face2int
erface.com/formINSTal/
> Webmaster's BBS - http://bbs.face2interf
ace.com/
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

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 <jerrymcmsu.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.cara
van.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
> 
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

On 2/26/07, Jerry McAllister <jerrymcmsu.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.cara
van.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://face2int
erface.com/formINSTal/
Webmaster's BBS - http://bbs.face2interf
ace.com/
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"