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