[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: input/output error on hd



On Fri, Feb 23, 2007 at 11:08:29AM -0500, Marty Landman wrote:

> On 2/23/07, Ian Smith <smithi_(_at_)_nimnet_(_dot_)_asn_(_dot_)_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>
> %
> 
> 
> 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?

I think maybe you might be getting some of your terminology shuffled 
around.    Your boot sector is not at question here.   It doesn't
affect the ability to read the disk partition.

Secondly, it looks like the slice table - which is what fdisk mucks
with - is OK.  

What seems to be messed up is either the slice 1 label which contains
the partition table.   In fact, with one of your postings, it looked
like it thinks it is slice 4, but I don't remember what you did to
get that.   

The one I do remember recently is the output from a 'bsdlabel ad1s1'
command and that showed a partition a and a partition c both containing
the entire slice and both marked as 'unused'.   

I would go back to that  bsdlabel ad1s1  and edit the 'a' partition
line so that the fstype field is changed from 'unused' to 'BSD4.2'
Then write that back just as with a normal 'vi' session (eg  ESCwq)
See what that does.   
Then try to do an fsck on /dev/ad1s1a  

If the bsdlabel does not show a partition 'a' like was mentioned in
a previous post, but only a partition 'c', then, as I suggeested one
of the times, make a partition 'a' that looks just like the 'c' one
but change the 'unused' to BSD4.2.   Leave the fstype for 'c' as unusued.

If none of this helps at all, then the problem is past the label and
in to the filesystem structure itself.   Then I think you are stuck with 
tracing superblocks as I pointed out before.   That is going to take some 
study but it might work.

////jerry

> 
> >%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?
> 
> 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
> %
> 
> If not, does bsdlabel ad1s2, ad1s3 or ad1s4, if fdisk ad1 shows anything in
> >s2, s3 or s4.
> 
> 
> s2-4 all show "No such file or directory" for bsdlabel
> 
> 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?
> 
> 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.
> 
> 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
> 
> 
> >And please don't top-post ..
> 
> 
> Sorry about that Ian, appreciate your help.
> 
> Marty
> 
> -- 
> Web Installed Formmail - http://face2interface.com/formINSTal/
> Webmaster's BBS - http://bbs.face2interface.com/
> _______________________________________________
> freebsd-questions_(_at_)_freebsd_(_dot_)_org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe_(_at_)_freebsd_(_dot_)_org"
_______________________________________________
freebsd-questions_(_at_)_freebsd_(_dot_)_org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe_(_at_)_freebsd_(_dot_)_org"