Dd /dev/random to disk


#1

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?


#2

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.


#3

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.


#4

What about good old /dev/zero?


#5

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.


#6

IMG_20190128_032440

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.


#7

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