Dd /dev/random to disk


I’m wiping some drives for a friend. 120GB drive is first up. My machine is 8 core Xeon, 32GB ram.
I ran:

dd if=/dev/random of=/path/to/disk/im/wiping bs=4M status=progress

The first time it ran 5MB/s. I let it run overnight and it was finished in the morning, about 8 hours. I woke up, ran the command exactly as before . It was chugging along at 5MB/s when I left for work. When I get home, I find it has dropped to 2MB/s and about half the progress that I was expecting to see was completed. It has now dropped to 1.9MB/s and is 14.5 hours after I started the second round. Why would my throughput drop by over half on the second run?


Does a reboot fix it? I assume you’re writing to /dev/disk/scsi/… to do the wiping, so there shouldn’t be any disk cache slowdown effects. Maybe the random number generator has slowed things down, try /dev/zero to generate the data for disk wiping and see if that speeds it up.


I’m trying to figure out why the same operation was half the speed the second time. It ended finally in kdl. I’ll post that later.


What about good old /dev/zero?


I did that too. It’s for a buddy. He wants the data dead and gone with no hope for recovery. And I want to test Haiku to see what I can break.



I’ll make a trac ticket too, if needed.

I ran it again with /dev/zero after rebooting. It crashed again upon completion, same kdl.


Yes, please do. Looks like there is a bug in the I/O scheduler.