> > > Are there any way I can figure out the position of one of the backup su=
> per-blocks?
> >=20
> > "Block 32 is usually an alternative super block."
> > 		fsck_ffs man page
> >=20
> > If that fails you can hunt for the superblock magic number.
> >=20
> > Be aware that running fsck on a filesystem with read errors can
> > make things worse.  (Give you one guess how I know that.)
> >=20
> > Safest thing to do is copy the filesystem somewhere, skipping
> > over the blocks that are unreadable, then run fsck on the copy
> > and see what happens.
> >=20
> > See also fsdb(8).
> 
> How can i skip copying them then?
> # dd if=3D/dev/wd1a of=3Drootdump.img
> dd: /dev/wd1a: Input/output error
> 128+0 records in
> 128+0 records out
> 65536 bytes transferred in 12.618 secs (5193 bytes/sec)

You could write a little shell script to dd one sector
at a time, using the skip and seek options.

Or you could write a little C program.

Perhaps keep track of the failing sectors and retry them
a few times.  Sometimes a retry will work.

If you want to retry reading bad sectors, you will need to
do "dkctl badsector flush" first, or the driver will not
really retry.

From a discussion in 2005-08:

} OK, I know what this is. There is a list of bad sector maintained by the
} wd driver, to return error without requesting an I/O to the drive (to avoid
} downgrades, and long hangs when trying to read a bad sector).
} The code doens't make a difference between read and write
} (while a write would likely remap the bad sector). You can use
} 'dkctl badsector' to see or flush this list. 
} A dkctl badsector flush followed by a write to this sector should fix it.