I have a (partially) broken drive which I will send in for replacement. I’d like to wipe the blocks that can still be read / written. I tried using diskutil with the Terminal command given below, but this seems to simply stop when it encounters any bad blocks (the progress bar gets to 1%, but then it stops, reporting “Input/output error”):

$ diskutil secureErase 0 /dev/disk1

Is there some way I can tell diskutil to not stop but rather continue with the next block it can still write? Or is there another command I could use?

  • Did you try it with the 'freespace' option? If it is addressable, but has the bad sectors marked as bad, that may help. If it is not addressable, you might consider a bulk eraser. – MrWonderful Jul 22 '14 at 20:53

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


In brief:

  1. download the UBCD image
  2. burn the image to CD
  3. set aside plenty of time for the destruction
  4. boot the Mac from the CD, this is very quick
  5. use the keyboard to select and open the Diagnosis submenu
  6. use the keyboard to select HDAT2
  7. accept a default
  8. at the command prompt, type hdat2 then key Enter or Return
  9. … 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).


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

  • be thorough with backups.


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

two photographs of HDAT2 two more photographs 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:

screenshot of SMART Utility, /dev/disk0 reportedly failing screenshot of SMART Utility, information for /dev/disk0 screenshot of SMART Utility, attributes for /dev/disk0

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.


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.

  • Thanks for the suggestions! I did not have any blank CDs on hand to try Ultimate Boot CD, so I wound up using the approach with ddrescue. It's available as a “port” from macports.org. – Rinzwind Jul 30 '14 at 20:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .