The goal in my case is not to securely erase data, but simply to force sector reallocation by the drives firmware.

I have a drive that has had a few file corruptions. It seems to be due to getting very hot at some point in the past, the max reported temperature is 99C ! I've recovered as much data from it as I can with ntfsclone --rescue and mounted the image.

The reallocated sector count is zero but the current pending sector count is 233.

If I write to the sectors then they will either be remapped or have their status restored , I'm wondering which is faster badblocks -w or dd or something else?

I've observed with iotop that badblocks is writing at about 17Mb/s which I don't think is very fast for this drive. dd from /dev/zero gives about 24Mb/s but it pauses frequently and the average seems about 13.5Mb/s, again seems too slow for this drive. At this rate it would take a whole day and night to zero the drive.

Perhaps I'm not using dd correctly and there are betters ways to make a large sequential write.

  • 1
    I added a block size argument to dd "bs=1m" and this seems to be giving a steady value of 30Mb/s which is better. – barrymac Feb 22 '12 at 13:28
  • 3
    try 4 or 8mb. my hunch is setting it to be whatever the drive's cache size is would be optimal. – Sirex Feb 22 '12 at 13:36
  • Agree w/bs=cache size, but are you trying to restore this drive for use? Are you doing this to recover data, or to prepare the disk for reuse? It sounds like this disk is ready for the bin. – bsd Feb 22 '12 at 14:02
  • 1
    Try ddrescue. – jofel Feb 22 '12 at 14:10
  • dd rescue looks great, but in this case I used ntfsclone because it's more space efficient and I don't quite have enough space for the full partition, but I do have enough space for the data. ntfsclone --rescue is similar – barrymac Feb 22 '12 at 23:37

If your goal is to really "zero" the drive, then I bet the fastest you can get is to issue a low-level secure erase command using hdparm (see here for step-by-step instructions).

Note two things:

  • As hdparm manpage vividly states, the operation is "DANGEROUS".
  • On the other hand, it may also repair bad blocks.
  • Of course, if the data on the device is already discounted as "lost", the low level erase isn't going to be able to do much more harm... – Shadur Feb 22 '12 at 14:40
  • Actually the goal is simply to get the drives firmware to reallocate or reinstate the pending sectors. I believe the drive might be stable but lost some data when it got hot at some stage – barrymac Feb 22 '12 at 23:35
  • @rozcietrzewiacz that link is great. hdparm really has some amazing features. I had no idea a firmware based secure erase even existed, you can even reset the whole device and re write over reallocated sectors! – barrymac Feb 24 '12 at 1:48
  • 1
    "As hdparm manpage vividly states, the operation is "DANGEROUS"." Why? – PetaspeedBeaver Dec 13 '16 at 17:53
  • 2
    @PetaspeedBeaver: That's a good question, actually. In short, there are several possible corner cases that may result in drive damage. Here are some considerations that come to my mind: a) the drive's firmware will be operating in a special mode for extended period of time, performing low-level operations - what if your system crashes in that period? b) You have limited possibilities of monitoring the actual state of the drive. c) Either the drive's firmware or your system's kernel can be faulty, each of which may lead to drive damage. – rozcietrzewiacz Dec 13 '16 at 20:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.