[RndTbl] disk cloning and bad blocks

[Kevin McGregor]

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 at 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 at shaw.ca
> (204) 831-1746
> answering machine always on
>
> _______________________________________________
> Roundtable mailing list
> Roundtable at muug.mb.ca
> http://www.muug.mb.ca/mailman/listinfo/roundtable
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.muug.mb.ca/pipermail/roundtable/attachments/20090819/a1e2d60b/attachment.html