Re: Question on shredding a terebyte drive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-           Give me ambiguity or give me something else!             -
----------------------------------------------------------------------

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux