On Wed, Sep 2, 2009 at 4:32 PM, Dean S. Messing <deanm@sharplabs.com> wrote:
I have a terebyte sata drive that I need to securely wipe clean.  It
originally had 2 partitions.  I deleted them using `fdisk', rebooted,
and then as root ran

   shred -vz /dev/sdd

The drive is capable of about 60MB/sec, but shred is only "shredding"
about 25MB every 5 seconds according to its output.  Since the default
number of passes is 25, this works out to about 5 days.

The `shred' process is running at 100% CPU, presumably computing
the special random patterns for erasure.  Since I have 4 CPUs
would creating 4 unformatted partions on the drive and then running
something like:

  shred -vz /dev/sdd1
  shred -vz /dev/sdd2
  shred -vz /dev/sdd3
  shred -vz /dev/sdd4

in parallel cut my time?  Would be just as secure?


The question is where the bottleneck lies.

If you think it's CPU bound because of rand bit patterns, shred it with just the non-random patterns (IIRC I think you set this by limiting iterations, the first few iterations are standard patterns: all zeros, all ones, 1010)

My other suggestion would be to use an old junker PC, plug in your drive and boot DBAN and let it churn away for a while.  DBAN may be optimized and may run faster (and probably does a more secure job) than shred.

--
-jp

If I was being executed by injection, I'd clean up my cell real neat. Then, when they came to get me, I'd say, "Injection? I thought you said `inspection'." They'd probably feel real bad, and maybe I could get out of it.

deepthoughtsbyjackhandey.com