how long to zero a drive with dd?

Question

How long will it take to zero fill 1TB (using dd dev/zero)?

I'm actually doing two 500G drive simultaneously if it matters.

Solution 1

It depends on many factors, including but not limited to:

• Disk speed (RPM)
• Disk built-in cache
• Number of platters and whether it can write to multiple platters simultaneously
• Disk interface (SATA/SCSI, etc)
• Interface controller performance
• Configuration of the drives (eg. separate channels or same channel)

Additionally, although zeroing a drive is a simple task for the CPU and RAM, there may still be an effect from:

• CPU performance
• Available RAM
• Speed of RAM
• Other tasks being done at the same time
• Power management settings

Assuming a fairly recent computer with middle-grade drives, on a minimal linux boot disk running JUST the zeroing operation (no gui, internet, etc) loaded entirely to RAM, it could be anywhere from 2-12 hours. If I had to throw a single number out, I'd say closer to 3 and a half hours, but again, there's not enough information to get a good estimate other than actually doing it.

If you have more than 1GB free space, you could try mounting the drive and running dd if=/dev/zero bs=512 count=2048 of=/tmp/tempzero or some other file. If you know more about the optimal block size for fastest writing to your drive, you can use that for the bs value (in kilobytes) and set the count to whatever gets you the filesize you want. Then you can use that to get a better estimate without losing data. It will just create a large file that contains zeros.

Solution 2

With a partition of +100 GB, Acer Aspire 5750G, external sata hdd, usb 2, 5400rpm:

xxxx@acer-ubuntu:~$ sudo dd if=/dev/zero of=/dev/sdb2 bs=8M
[sudo] password for xxxx: 
dd: writing `/dev/sdb2': No space left on device
12500+0 records in
12499+0 records out
104856551424 bytes (105 GB) copied, 2846.87 s, 36.8 MB/s

and

xxxx@acer-ubuntu:~$ sudo dd if=/dev/zero of=/dev/sdb1 bs=8M
[sudo] password for xxxx: 
dd: writing `/dev/sdb1': No space left on device
6579+0 records in
6578+0 records out
55183409152 bytes (55 GB) copied, 1497.23 s, 36.9 MB/s

Solution 3

I did a dd with random data on a 750GB drive. I think it took about 20 hours. The thing that really sucked about it, is I had to do that four times for a four disk RAID array. I think the bottleneck is the write speed of your drives. You're being smart to do it to the drives in parallel.

Solution 4

If you're just erasing the drives, a great tool to use for parallel throughput is DBAN in simple erase mode. It's available as an ISO and basically does the dd if=/dev/zero command for you on the drives you select.

Solution 5

I'm guessing, but my guess is that it would depend on the drive controller, the controller on the motherboard, and what else is soaking up CPU/IO.

My guess, on the order of hour or hours. Days seems long. Depending on how your machine is set up, running both at the same time may actually slow things down if you create contention for the drive controller. Even though you're pumping out zeros, nothing in your drive knows that and it needs to write every byte.

View more solutions

Comments

[Sam Bisbee]

A large part of your performance issue was likely your using random numbers. /dev/urandom or any other source is going to try very hard to generate truly random numbers, thereby dropping your throughput. Something like /dev/zero won't have that problem.

[barlop]

@crazyscot yes massive difference there with the bs=1M to override the terrible default of bs=512. Also ddrescue(check how to set block size in it), gives a percentage/progress bar.

[pufferfish]

Is there any risk of 1TB of zeros being compressed somewhere in the pipeline down to storage, and skewing the results? I don't mean actually compressed on the disk, but in transit as a optimisation

[alper]

Does DBAN work in linux or mac?

[alper]

dd if=/dev/zero of=/dev/disk2 bs=8M is pretty slow as (352 kB/s) is it normal? can I make it faster?