How to erase the working blocks on a partially broken drive?
HDAT2 5.0

Version 5.3.0 of Ultimate Boot CD (UBCD) includes HDAT2 5.0. 

A July 2014 Apple Support Communities topic – Storage problems, Core Storage, Disk Utility, checksums, fsck_cs and cksum mismatches – included photographs of me using the 'most powerful test' of HDAT2 with a 2009 MacBookPro5,2. (That topic no longer exists, only parts of it were saved locally. I'll append this answer with some of that topic content, slightly adapted.)

Amongst the other features of HDAT2, there's the ability to destroy data …

Suggestion

In brief: 


download the UBCD image
burn the image to CD
set aside plenty of time for the destruction
boot the Mac from the CD, this is very quick
use the keyboard to select and open the Diagnosis submenu
use the keyboard to select HDAT2
accept a default
at the command prompt, type hdat2 then key Enter or Return
… and from there things should be self-explanatory


– just take care to select the correct drive before proceeding with destruction. 

(I'm working from memory, whilst my copy of UBCD is running in my other Mac … the actual routine might differ slightly from what's above but the general idea should be the same.)

Hint: HDAT2 is powerful and versatile, so the documentation may appear daunting, but this should not be an obstacle. If you skip the manual, the on-screen routines are well-designed – alongside technical phrases, in many areas there are plain english hints. 

In Super User

How to erase a hard drive with unwritable sectors?

– a few good answers, but the accepted answer there involves ddrescue, which is not integral to OS X. 



Originally posted to Apple Support Communities

If ever you see the following phrase in red in Disk Utility –


  ... cksum mismatch ...


– treat it as a red alert that should not be ignored.

Whilst a subsequent run of Disk Utility may complete without error – whilst the utility may state that a volume appears to be OK – you should not assume that the affected storage is completely OK.

Aim to check all affected devices. So if the checksum mismatch affected a Fusion Drive – or any other application of Core Storage that involves multiple devices – aim to check the whole of each physical device within the affected Core Storage logical volume group (LVG).

Precautions

Some approaches to identification of failing drives (failing e.g. bad blocks) may cause dataloss. So, the usual advice:


be thorough with backups.


Example

On Friday 2014-07-11, whilst running running a released version of OS X on a MacBookPro5,2 with an internal solid state hybrid drive (SSHD), ￼some software behaved in ways that made me suspect a failing disk. 

Saturday morning, from a Disk Utility log:

2014-07-12 08:01:41 +0100: Checking volume
2014-07-12 08:01:41 +0100: disk0s2: Scan for Volume Headers
2014-07-12 08:01:41 +0100: disk0s2: Scan for Disk Labels
2014-07-12 08:01:41 +0100: Invalid Disk Label @ 132817997824: cksum mismatch


Minutes later, a subsequent verification completed with no mismatch. Disk Utility described volumes as apparently OK.

I could have ignored that mismatch as a one-off – maybe something transient. However, the previous day's observations – some of which are confidential (and unrelated to Apple) – made me believe that neither fsck_cs nor fsck_hfs would be capable of revealing the nature of the problem. (It's not clear what approach to scanning is taken when fsck_hfs is used with option -S, and so on.)

I decided to boot from Ultimate Boot CD 5.3.0 and use the most powerful test in HDAT2.

During use of HDAT2




After use of HDAT2

I booted from a different physical disk (external), and refrained from unlocking all Core Storage logical volumes on the affected disk (internal) – whilst I await replacement, I wish to minimise use of the drive.

Because Disk Utility can not display S.M.A.R.T. information for disks where Core Storage is used, I ran the nearest available alternative (SMART Utility, on trial) to gain an alternative view of the state of the SSHD. In this case, things seem perfectly clear; the disk is failing:





Reviews with Apple Disk Utility

Subsequent runs of Disk Utility, e.g. from Recovery OS 10.9.4, continue to describe the affected volumes as apparently OK.

Related

In a topic in MacRumors Forums: Disk Utility, checksums, fsck_cs cksum mismatches and disk/storage problems. Note:


  I should not treat Yosemite as a cause of storage-related problems of
  this type. …




Other parts of that Apple Support Communities topic are lost to me. 

Update, 2014-12-12

Still using the same disk, checksum mismatches have been rare. A summary, maybe not comprehensive: 

2014-07-01 22:18:42 +0100: Invalid Disk Label @ 132809609216: cksum mismatch
2014-10-02 13:01:37 +0100: Invalid Disk Label @ 133167747072: cksum mismatch
2014-10-07 09:41:43 +0100: Invalid Disk Label @ 133176135680: cksum mismatch
2014-11-08 04:13:17 +0000: Invalid Disk Label @ 133163552768: cksum mismatch
2014-11-13 18:25:07 +0000: Invalid Disk Label @ 133163552768: cksum mismatch
2014-12-02 09:02:58 +0000: Invalid Disk Label @ 133171941376: cksum mismatch 


I no longer plan to replace the drive; I'll get a newer computer.