Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

While securely erasing a hard drive before decommissioning I noticed, that dd if=/dev/urandom of=/dev/sda takes nearly a whole day, whereas shred -vf -n 1 /dev/sda only takes a couple of hours with the same computer and the same drive.

How is this possible? I guess that the bottleneck is the limited output of /dev/urandom. Does shred use some a pseudorandomness generator that is less random and only sufficient for it's single purpose (i.e. more efficient) than urandom?

share|improve this question
    
Note that the best option for erasing drives, especially ssd drives, is the SATA secure erase command. Any other option - barring destruction - will fail. Its much faster too, and may just take seconds on an SSD. – Maarten Bodewes Jul 21 at 15:58
up vote 10 down vote accepted

Shred uses an internal pseudorandom generator

By default these commands use an internal pseudorandom generator initialized by a small amount of entropy, but can be directed to use an external source with the --random-source=file option. An error is reported if file does not contain enough bytes.

For example, the device file /dev/urandom could be used as the source of random data. Typically, this device gathers environmental noise from device drivers and other sources into an entropy pool, and uses the pool to generate random bits. If the pool is short of data, the device reuses the internal pool to produce more bits, using a cryptographically secure pseudorandom number generator. But be aware that this device is not designed for bulk random data generation and is relatively slow.

I'm not persuaded that random data is any more effective than a single pass of zeroes (or any other byte value) at obscuring prior contents.

To securely decommission a drive, I use a big magnet and a large hammer.

share|improve this answer

I guess it would be caused rather by dd using smaller chunks to write the data. Try dd if=... of=... bs=(1<<20) to see if it performs better.

share|improve this answer
    
I'll try that on the next occasion and post the results. – agporwfnz29 Apr 30 '12 at 9:06
    
+1 Default dd block size is 512. It performed way below disk limits on my computer. – Piotr Findeisen Jan 12 '14 at 22:56
    
/dev/urandom is likely plenty fast - the dd block size is almost certianly the issue. – Dan Pritts Jun 19 '14 at 17:13
    
Once you increase the block size it seems like /dev/urandom can become a bottleneck - I'm testing some SSD drives over USB 3.0 and with the same dd command I get 326 MB/s for if=/dev/zero but only 12.8 MB/s for if=/dev/urandom – austinmarton Jun 12 '15 at 5:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .