input/output error on hd

[Ian Smith]

On Fri, 23 Feb 2007, Marty Landman wrote:
 > On 2/23/07, Ian Smith <smithi at nimnet.asn.au> wrote:
 > 
 > So just show 'fdisk ad1' to see the disk's partition (slice) table (which
 > > may be damaged, but it's the only one you're interested in).
 > 
 > %sudo fdisk ad1
 > ******* Working on device /dev/ad1 *******
 > parameters extracted from in-core disklabel are:
 > cylinders=486344 heads=16 sectors/track=63 (1008 blks/cyl)
 > 
 > Figures below won't work with BIOS for partitions not in cyl 1
 > parameters to be used for BIOS calculations are:
 > cylinders=486344 heads=16 sectors/track=63 (1008 blks/cyl)
 > 
 > Media sector size is 512
 > Warning: BIOS sector numbering starts with sector 1
 > Information from DOS bootblock is:
 > The data for partition 1 is:
 > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
 >     start 63, size 490223412 (239366 Meg), flag 80 (active)
 >         beg: cyl 0/ head 1/ sector 1;
 >         end: cyl 1023/ head 254/ sector 63
 > The data for partition 2 is:
 > <UNUSED>
 > The data for partition 3 is:
 > <UNUSED>
 > The data for partition 4 is:
 > <UNUSED>
 > %

Ok, that looks right, doing the maths on cyl x heads x s/tk x 512 bytes.

 > If 'fdisk ad1' isn't showing any sensible data for 'partition 1' (ad1s1)
 > > then your boot sector is hosed.
 > 
 > 
 > Does the above result mean that my boot sector is ok?

Looks like.  By 'boot sector' here we're talking about sector 0 on ad1,
which while it isn't your real boot sector (that's on ad0), it is where
the ad1 partition table is stored, and is what fdisk is looking at here.
It's also what 'boot0cfg -v ad1' should show you, re the slicing.

I should mention here that I've read Jerry's reply, and (digging through
the latest freebsd-questions digest) your reply to him, but you left me
out of the ccs.  I keep hearing that gmail makes doing proper followups
difficult; you may have to make an extra effort to keep everybody cc'd.

 > > %sudo fsck /dev/ad1cs1
 > > > fsck: Could not determine filesystem type
 > > > %sudo fsck /dev/ad1c
 > > > fsck: exec fsck_unused for /dev/ad1c in /sbin:/usr/sbin: No such file or
 > > > directory
 > >
 > > You shouldn't be doing any of this with the 'c' partition, which is meant
 > > to cover the whole disk, but doesn't describe any of its slices.
 > 
 > Unfortunately I had incorrectly been using ad1s1c for this disk, is there
 > anything I can do about it now? Would that help with the effort to recover
 > the data?

What we seem to be unsure of is how the disk was originally partitioned. 

Normally if you'd used sysinstall to allocate the entire second disk to
a single freebsd slice, it would have showed up as (possibly) ad1s1a or
(more likely) as ad1s1d, going on what happens to non-bootable freebsd
slices here.  In any case, you need to construct a good label for it. 

 > I gather you think your data should be on ad1s1.  Does 'bsdlabel ad1s1' say
 > > anything sensible?
 > 
 >  %sudo bsdlabel ad1s1
 > # /dev/ad1s1:
 > 8 partitions:
 > #        size   offset    fstype   [fsize bsize bps/cpg]
 >   c: 490223412        0    unused        0     0         # "raw" part, don't edit

Ok, apart from not having an a or d or whatever partition, it looks ok.

 > As you mentioned elsewhere, you appear to have a bunch of bad blocks early
 > > on this disk.
 > 
 > Yes, based on working with the dd cmd on /dev/ad1s1 and playing with the
 > skip parm have found that blocks 129-144 give input/output errors. Does this
 > indicate a hardware error necessarily? This problem came about as the result
 > of a power outage; might there "just" be hosed data on those sectors?

Not to get your hopes up too high, but yes it's possible to hose a bunch
of sectors, especially on a power outage at a bad moment, without there
being any physical damage, so yes these might come good when re-written.
I had exactly that happen to a 15GB IBM drive, which newfs fixed ok,
after I'd spent ages getting what was recoverable off it.

However it depends on what was on those sectors, and from the numbers at
63 sectors/track, they could be superblock &/or root directory sectors,
which likely spells difficulty for recovery. 

 > Have you a spare drive you can dd this one to, in its current state?
 > 
 > No, it's a 250GB drive, the largest on my LAN. Would have to buy a
 > replacement drive and then dd to that. If it came to that, while a backup hd
 > might be a good idea, I'd possibly just live with recreating the data
 > instead.

Well I'd at least try getting a copy of the first few some tens of megs,
whatever you can afford to dd elsewhere.  I've not used it, but look at
'conv=noerror' in dd(1) which should copy it ok replacing the unreadable
sectors with nulls but preserve the rest, hopefully including some other
superblocks, which you may have to hunt for, to give to fsck.

 > What does 'ls -l /dev/ad1*' have to say?
 > 
 > %ls -al /dev/ad1*
 > crw-r-----  1 root  operator    0,  70 Feb 22 17:56 /dev/ad1
 > crw-r-----  1 root  operator    0,  74 Feb 22 17:56 /dev/ad1a
 > crw-r-----  1 root  operator    0,  75 Feb 22 17:56 /dev/ad1c
 > crw-r-----  1 root  operator    0,  82 Feb 22 17:56 /dev/ad1cs1
 > crw-r-----  1 root  operator    0,  94 Feb 22 17:56 /dev/ad1cs1c
 > crw-r-----  1 root  operator    0,  73 Feb 22 17:56 /dev/ad1s1
 > crw-r-----  1 root  operator    0,  84 Feb 22 17:56 /dev/ad1s1c

Yeah that's a bit confusing.  Hopefully with the right label you'll get
an ad1s1a or ad1s1d or something usable. 

Now, blowing protocol, I'll paste and patch your reply to Jerry in here
from the latest digest:

 > On 2/23/07, Jerry McAllister <jerrymc at msu.edu> wrote:
 >
 > > I would go back to that  bsdlabel ad1s1  and edit the 'a' partition

 > Also changed the size and offset to match the 'c' partition. Looks
 > like progress here but still haven't gotten all the way to a mount as
 > you can see:
 >
 >
 > %sudo bsdlabel -e /dev/ad1s1
 > # /dev/ad1s1:
 > 8 partitions:
 > #        size   offset    fstype   [fsize bsize bps/cpg]
 >  a: 490223412        0    4.2BSD        0     0
 >  c: 490223412        0    unused        0     0         # "raw" part, don't edit

That first 'a' partition entry should have a third '0', going by my
labels here.  Maybe that's why below it says 'incomplete'? 
 
Maybe someone who's got a full-disk partition on a non-boot disk could
assist here?  Especially as to whether the correct start sector offset
should really be 0?  And the likely? location of other superblocks, or
the root directory, on such a disk.

 > %sudo fsck /dev/ad1s1a
 > ** /dev/ad1s1a

 > CANNOT READ BLK: 128
 > CONTINUE? [yn] y

 > THE FOLLOWING DISK SECTORS COULD NOT BE READ: 128, 129, 130, 131,
 > 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143,

Seems to match your dd experiences, though you said blocks 129-144, so
there's maybe an off-by-one thing here with dd blocks and fsck sectors?

 > /dev/ad1s1a: INCOMPLETE LABEL: type 4.2BSD fsize 0, frag 0, cpg 0,
 > size 490223412

Ok, that looks like it's at least aiming at the right place, and has
recognised the slice and partition, but the label isn't quite right.  I
don't know if you'll need to fill in the fsize, frag, cpg stuff, I'm
more than a bit out of my depth regarding that ..

 > %sudo mount /dev/ad1s1a /hoss
 > mount: /dev/ad1s1a: Input/output error
 > %sudo fsck -y /dev/ad1s1
 > fsck: Could not determine filesystem type

I think you might want to be a bit careful of using fsck -y until you're
sure you've got the label exactly right.  fsck -n is always safe to
check things with, as it changes nothing, and you might be able to poke
around with it trying to find other superblocks that might help out .. 

Good luck!

Ian