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

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

link|improve this question
So, tell us, how long did it take to dd the drives with zeros? – Rolnik Mar 28 '11 at 19:38
My WD 1Tb (5400rpm) sata takes about 240 minutes, but it's old and has reallocated sectors. Incidentally it's not that different from the same time that smart reports as the time to expect an extended self test to last (255mins) – barrymac Mar 1 at 14:57
feedback

4 Answers

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.

link|improve this answer
2  
In my experience on hard drives of the last decade or so, bs=1M is a vast improvement over bs=512 and is good enough to use as a default without worrying too much about finding the optimal. – crazyscot Apr 10 '11 at 21:52
feedback

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.

link|improve this answer
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. – Sam Bisbee Nov 11 '11 at 19:45
feedback

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.

link|improve this answer
feedback

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
link|improve this answer
feedback

Your Answer

 
or
required, but never shown

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