Is shred cpu bound? I see two ways to test: Fill the drive from /dev/zero . cp is not cpu bound. Run top while shred is running. top will tell you how much cpu time shred has used. After an hour, divide the number of shred's cpu seconds by 36 to get the percentage. If random number generation is the problem, you can replace it by passing shred a named FIFO. Pick two relativle prime integers, both larger than one million. Use these as the sizes of two arrays, call them A and B. Fill them from /dev/random . byte(j) = A[j%sizeof A] ^ B[j%sizeof B] Unlike urandom, random can block, so the fill step could be slow. urandom, wh3en random would block uses pseudo-random numbers, so either way, you will be using pseudo-random numbers. IIRC shred doesn't just write different data patterns on different passes, it also write blocks in different orders. That can affect the precise placement of the r/w heads and can cause shred to affect more of the platter area. As other have noted, company policy seems just a bit silly. Using any of the following tools would seem cheaper and more effective: degausser sledge hammer arc welder NaK bath shred-ing would seem more appropriate for an internal drive. A preference for shred-ing over cracking a case seems rational to me. -- Michael hennebry@xxxxxxxxxxxxxxxxxxxxx "Pessimist: The glass is half empty. Optimist: The glass is half full. Engineer: The glass is twice as big as it needs to be." -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
