Comments on: Thinking things through: dd over USB1.1

By: M. Klay

M. Klay — Sat, 28 Aug 2010 07:10:38 +0000

of course it is…

By: Foz

Foz — Wed, 25 Aug 2010 14:06:15 +0000

Dismantle an old hifi speaker. The woofer magnets are fantastic!

By: Zach

Zach — Wed, 25 Aug 2010 05:41:26 +0000

If you zero a drive, a compressed image created of that drive can be compressed a bit more than a disk filled with random data. IIRC

By: Wavefunction

Wavefunction — Wed, 25 Aug 2010 03:24:44 +0000

There were a few posts on linux.com and other locations where people checked the throughput of /dev/zero, /dev/urandom, and various options while running dd. (dd is pretty much -the- secure deletion tool. If you want it shredded, use dd.) In short, /dev/urandom generated data at about 1/10th the speed of /dev/zero, even when accessing internal drives. If I recall correctly, the fastest /dev/urandom ever worked was something like 7.5MB/s.

And, as anecdotal evidence, I /dev/urandom against a 1TB (1000GB) internal hard drive and it took about 38 hours to complete on the fastest machine in the house. (8GB ram, 2.8Ghz six-core processor, etc.)

By: K.Mandla

K.Mandla — Tue, 24 Aug 2010 23:58:25 +0000

No one seems to mention block sizes. Is that not worth adjusting?

By: K.Mandla

K.Mandla — Tue, 24 Aug 2010 23:56:15 +0000

/dev/zero might have been faster than waiting on /dev/urandom. I’ll try that next time.

By: K.Mandla

K.Mandla — Tue, 24 Aug 2010 23:54:41 +0000

Where do people buy these mystical magnets that everyone always suggests for killing a drive? And for goodness sake, what do they keep them in that doesn’t cause them to erase everything in the entire house?

By: K.Mandla

K.Mandla — Tue, 24 Aug 2010 23:53:13 +0000

Yes, I should have checked its progress before cutting it off, but I wasn’t in a hurry and the machine runs 24/7, so I let it go until I just felt finished with it.

Both lsusb and dmesg suggest it’s a 12M port, so I suppose it could be just a slow interaction between /dev/urandom and the drive itself. I did notice that it tended to write in bursts, pausing and (I assume) caching the information to be written, then sending pulses to the drive all at once.

htop marked the process as “uninterruptible” during those write phases. I wonder if that cache-and-pulse writing had anything to do with the delay?

By: mulenmar

mulenmar — Tue, 24 Aug 2010 23:25:21 +0000

+1 to this. Here’s the command I use:

# nice -n -15 dd if=/dev/zero of=/dev/sdX

sdX, of course, being the drive I’m blanking out.

By: Mister Shiney

Mister Shiney — Tue, 24 Aug 2010 14:53:17 +0000

I had to laugh when I read this, because for the past several days I’ve been trying to move a bunch of data from an old HDD I had in an external enclosure over to a new external HDD. No matter what I did, the enclosure was recognized at the 12Mbps speed (USB 1.1). It took over 30 hours to move the data. I spent a lot of time reviewing oodles of bug reports about USB issues in Ubuntu and even went as far as upgrading to Lucid (I usually like to lag a few versions since stability is more important to me than being on the bleeding edge). Anyway, I went as far as to remove the drive from the enclosure and try in several others — generally with the results that the drive was recognized as high speed, reset by the system, and disconnected. It was not until later that I realized two things: jumper settings are very important in USB enclosures, and the first enclosure was more forgiving of jumper settings — also, one of the pins on the drive was broken off into the ribbon connector on the first enclosure. That last explained why the drive only worked in that one enclosure. Anyway live and learn — after 30+ hrs I copied the data off the drive and scuttled it.