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.
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
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
