Question on shredding a terebyte drive

Jake Peavy djstunks at
Wed Sep 2 21:37:18 UTC 2009

On Wed, Sep 2, 2009 at 4:32 PM, Dean S. Messing <deanm at> 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.


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
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the users mailing list