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