1

If I issue the following command to completely erase a disk, will it automatically stop when the disk is full, or do I need to specify the count option?:

sudo dd if=/dev/zero of=/dev/disk7 bs=64m

I should mention this os OS X 10.9.

Elliott B
  • 1,103
  • 4
  • 13
  • 35

2 Answers2

1

It will stop when the disk is full

Lawrence
  • 4,265
  • 14
  • 21
1

completely erase a disk

If your goal is to make a mechanical disk (HDD) securely erased so that it is impossible, even in principle, for someone to get their hands on it and recover the data, you should not be using /dev/zero as the source, and you should be writing over it more than once. See wikipedia and about.com.

If you don't care about security, /dev/zero is fine, but then, so is just putting a new partition table on the device.

I really can't see a valid use case for writing /dev/zero onto physical media, because:

  1. It's too insecure if you care about security;
  2. It takes too long and wastes time and write cycles if you don't (because you can simply overwrite whatever data structures are on the disk with new ones, meaning that only a data recovery program would have a hope of recovering fragments of the old data, and that's fine because you just said you don't care about security, or if you do, you shouldn't be reading this).

automatically stop

Of course. What do you think it's going to do, keep writing onto the next file?

You specifically specify the of option, which means "output file". It will open that block device and write until it reaches the end of the block device, then exit. This is normal behavior for dd.

do I need to specify the count option?

You'd only do that if you want it to stop writing at some point before it reaches the end of the block device, or if you're writing to a regular file (i.e., not a block device) and you want it to stop before it fills up the filesystem that the file sits on.

Some closing notes:

  • This behavior is not specific to (any particular version of) OS X, or even to OS X. It works the same on Linux, Android, the BSDs, and probably others that implement POSIX standards.
  • You could have answered your own question by making a small (2 MB) image file and using dd on it after mounting it on a loopback device, then run dd on it.
  • It should be noted that without count specified, dd will stop when the first of one of the following conditions occurs: either the if (input file) throws an EOF (end of file), or the operating system throws a signal indicating that the last block of of (output file) has been reached.
allquixotic
  • 34,215
  • 7
  • 113
  • 145
  • Thanks. I don't care about security here, but I suspected a bad partition table, so I wanted to zero it out. – Elliott B Mar 05 '14 at 03:20
  • 1
    Simply creating a new partition table on top of the old one will eliminate any problems you had with the old one, no matter how broken the old one was. Zeroing serves no purpose whatsoever in your use case. – allquixotic Mar 05 '14 at 03:23
  • 1
    The data sanitization method referenced by about.com is from the '90s. It was necessary at the time, but the Wikipedia page you linked to quotes a NIST publication from 2006: "Studies have shown that most of today’s media can be effectively cleared by one overwrite" and "for ATA disk drives manufactured after 2001 (over 15 GB) the terms clearing and purging have converged." Actually, according to studies, overwriting the disk with `/dev/zero` is quite secure. See [zero fill vs random fill](http://superuser.com/a/522765/101836). – Dennis Mar 05 '14 at 03:25
  • @Dennis Secure enough for most people, sure. But even if there is strong scientific evidence that a zero fill is sufficient, there are still going to be people who choose, for one reason or another, to do a random fill and/or multi-pass. But the level of security added by such methods, while infinitesimal, is probably nonzero, just like you can take a ridiculously secure crypto cipher with no known vulnerabilities or weaknesses and a more-than-sufficient key length, double its key length, and get an even "more" secure key. *How* much more? Well... not much. But it's up to the person to decide. – allquixotic Mar 05 '14 at 03:45