My understanding is that modern hard drives detect bad sectors and substitute ones from a set of 'spares', but when they run out of spares, well... time to get a new drive. Replace it on warranty if you can, but either way, the drive is done for. If you can do a file-based backup more than once, you can checksum the files and compare the checksums to see if the copies are good (or at least failed in the same place), but yeah, it's hard to tell how trustworthy the data is at that point, hence all the urging to start doing backups before this happens.

Kevin

On Wed, Aug 19, 2009 at 10:59 AM, Dan Martin <ummar143@shaw.ca> wrote:
>

Further to my adventures attempting to clone the boot drive of my
Mac ...

I attempted cloning using dd - the idea being that a block copy would
avoid any issues with metadata that might be encountered using file
transfers.  I/O errors were encountered (I believe a read on the
source drive was cited).

CCC failed in block mode, and subsequently defaulted to file mode in
spite of copying between identical types of drives.  Then it failed in
file mode.

SuperDuper (copies in file mode only) appeared to have no difficulty -
though the target drive would not boot until I did it a second time.
I have since made more copies which appear to boot.  Given previous
failures, I am not sure how much to trust that I have a faithful
reproduction of the source drive (not that I have any other real
choices).

I assume there is(are) bad block(s) on the source drive.  Given the
size of modern drives (this one a Seagate 750GB), statistically I
expect bad blocks.

In general, shouldn't bad blocks be hidden by the firmware on the
drive?  I thought there was an internal mapping mechanism on the drive
to exclude the use of bad blocks, which was invisible to even low
level use such as the dd command.

Failing this, such as 'when good blocks go bad', the filesystem (HFS+
and I presume most other modern filesystems) will catalog any known
bad blocks to avoid using them for files.

Should I be trying to return a warrantied drive after read errors
occur?  Discard it if it is not warrantied?

If the filesystem has isolated all bad blocks on the source drive,
then dd conv=noerror should work so long as there are no bad blocks on
the target drive.  Does conv=noerror pad the missing/unreadable data
so that the ends of the source and data drive/partitions 'line up'?
HFS+ stores important info in the last 2 sectors.

After cloning, how do you verify identical file contents between
clones?  After a file level copy using SuperDuper, a comparison using
FileMerge shows that many files do not match (I booted to one, so
Spotlight data will differ).  I think FileMerge complains about
identical identifying data between the clones that it is asked to
compare, though there is no problem mounting identical clones.

Since I happened to be at an Apple Store in Minneapolis, I purchased
DiskTools Pro, which is advertised to "fix bad sectors" - identifying
which files are affected by them.  I am not sure how much to trust it,
especially with destructive operations like defrag.  I hope to try the
"fix bad sectors" soon.  Does anyone have experience with DiskTools Pro?

Dan Martin
GP Hospital Practitioner
Computer Scientist
ummar143@shaw.ca
(204) 831-1746
answering machine always on

_______________________________________________
Roundtable mailing list
Roundtable@muug.mb.ca
http://www.muug.mb.ca/mailman/listinfo/roundtable