<div class="gmail_quote">On Wed, Sep 2, 2009 at 4:32 PM, Dean S. Messing <<a href="mailto:deanm@sharplabs.com">deanm@sharplabs.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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? <a href="http://fedoraproject.org/wiki/Communicate/MailingListGuidelines" target="_blank"></a> </blockquote></div> 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. <a href="http://deepthoughtsbyjackhandey.com">deepthoughtsbyjackhandey.com</a>