Question on shredding a terebyte drive
djstunks at gmail.com
Wed Sep 2 21:37:18 UTC 2009
On Wed, Sep 2, 2009 at 4:32 PM, Dean S. Messing <deanm at 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.
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