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]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux