Question on shredding a terebyte drive

[Rick Stevens]

Dean S. Messing wrote:
> Thanks to all for the replies.
> 
> I'll answer most of the comments here.
> 
> 0) The disk is unmounted.
> 
> 1) The drive is (was) a backup drive with a great deal of sensitive
>    corporate laboratory research data and algorithms on it.  The
>    monitary loss of the data being stolen would be significant though
>    it's hard to put a $$ value on it.  More importantly, I'm following
>    corporate policy.
> 
> 2) The drive is under extended warranty and so I'm sending it back for
>    a new drive.  The Power Supply in the enclosure is bad.  The actual
>    drive is still good, but they want the whole thing back for a
>    replacement.  Sanding off the oxide and then melting the drive
>    probably won't go over well with the manufacturer.
> 
> 3) Writing zeros is a not a good idea if the data is valuable.  The
>    small latent magnetic orientation info left from the previously
>    written data is not _that_ hard to recover with $5000 equipment, so
>    I've read.  Multiple passes of random patterns are needed to make
>    recovery costly.
> 
>    Tony Nelson's remark about newer drives having overlapping data
>    tracks is interesting and I don't know what current research says
>    about the effects of that on recovery, but Gutmann's (slightly old)
>    paper from 1996:
> 
>      <http://www.cs.auckland.ac.nz/%7Epgut001/pubs/secure_del.html>
> 
>    says in Section 2:
> 
>       When all the above factors are combined it turns out that each
>       track contains an image of everything ever written to it, but
>       that the contribution from each "layer" gets progressively
>       smaller the further back it was made. Intelligence organisations
>       have a lot of expertise in recovering these palimpsestuous
>       images.
>    
>    Which is why 25 passes meets DoD (and my corporate) standards.
> 
>  4) I don't know if the fact that the process runing at 100% of one CPU
>     means it is compute bound.  Looking at the disk I/O meter in
>     gkrellm I see bursts of writes followed by intervals of no
>     transfer.  I know that magnetic reorientation requires some time
>     to "set" and that may be why the delays are there.  Or it may be
>     compute bound.

Run "top" and you may find that the shred process is in a "D" state a
lot of the time.  That means it's in an I/O wait state, waiting on the
drive to complete some operation.  A "D" state can suck up a lot of CPU.

> Thanks for all the interesting comments on my question.  At this point
> I think I'll just let the thing run for the five days.
> 
> Dean
> 


-- 
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer                      ricks at nerd.com -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-           Give me ambiguity or give me something else!             -
----------------------------------------------------------------------