Strange DD Speed Problem

benchmarkman · 10-26-2009, 07:37 PM

I am often creating clones of hard drives and I have come across something I don't understand. If I DD to a hard drive that has been previously used, the DD takes about 35 minutes. If I clone to a completely brand new drive, the DD takes over 100 minutes. If I immediately run the DD command again, on the same set of drives, the DD now only takes 35 minutes. Why are brand new drives causing the DD to take 70 extra minutes?

smeezekitty · 10-27-2009, 01:04 PM

what happens if you delete all partitions and dd it again
is it slow again?

benchmarkman · 10-27-2009, 04:42 PM

I have not tried that. I'll try that some time this week. How would I delete all the partitions?

smeezekitty · 10-27-2009, 07:22 PM

Quote:

Originally Posted by benchmarkman

I have not tried that. I'll try that some time this week. How would I delete all the partitions?

fdisk

benchmarkman · 10-30-2009, 03:57 PM

So I cleaned the drive before DD and it only took 40 minutes. I'm really confused why would a brand new drive cause DD to take twice as long. I've reproduced this more than 10 times so I know it wasn't random.

smeezekitty · 10-30-2009, 04:07 PM

Quote:

Originally Posted by benchmarkman

So I cleaned the drive before DD and it only took 40 minutes. I'm really confused why would a brand new drive cause DD to take twice as long. I've reproduced this more than 10 times so I know it wasn't random.

maybe there is some sort of first time use setup? i do not know.

benchmarkman · 10-30-2009, 04:23 PM

Quote:

Originally Posted by smeezekitty

maybe there is some sort of first time use setup? i do not know.

I thought DD was straight dumb copy to copy ?

benchmarkman · 11-07-2009, 06:10 AM

Nobody has a reasonable explenation on what I am seeing?

AwesomeMachine · 11-07-2009, 11:35 AM

I'm not sure exactly why DD does this, but I do know new drives are written many times with solid binary 1s (ones), or 0xff, over the entire drive. Whereas a used drive has all the free space written as binary zeroes. The DD buffers may be choking on the binary 1s. DD buffers every block 4 times for each read/write. It could be a programming flaw. The other thing is if MSWindows was installed on the drive, DD won't overwrite the whole drive on the first try. If you DD a drive with zeroes, but Windows is on the drive, parts of the drive won't erase until the second time you run DD. Windows has some way of causing this to happen. I never did figure it out. So, the way around the Windows problem is to run DD for a count=10,000, several times in a row, reboot, and run a full DD.

benchmarkman · 11-07-2009, 12:31 PM

Quote:

Originally Posted by AwesomeMachine

I'm not sure exactly why DD does this, but I do know new drives are written many times with solid binary 1s (ones), or 0xff, over the entire drive. Whereas a used drive has all the free space written as binary zeroes. The DD buffers may be choking on the binary 1s. DD buffers every block 4 times for each read/write. It could be a programming flaw. The other thing is if MSWindows was installed on the drive, DD won't overwrite the whole drive on the first try. If you DD a drive with zeroes, but Windows is on the drive, parts of the drive won't erase until the second time you run DD. Windows has some way of causing this to happen. I never did figure it out. So, the way around the Windows problem is to run DD for a count=10,000, several times in a row, reboot, and run a full DD.

Thanks for the reply. It's not a windows thing because the drivers are brand spanking new. Have you ever encountered this problem yourself? Is there anyway around this?

smeezekitty · 11-07-2009, 12:48 PM

maybe dd is buggy?

benchmarkman · 11-07-2009, 01:52 PM

If thee was a bug in dd this significant wouldn't other people have experienced this problem? It seems like nobody else is having this problem.