We've been utilizing an internal tool/userspace/stack/thing here for a number of years that, along with performing other maintenance tasks, uses shred version 5.2.1 (which was packaged with an old version of Ubuntu, I believe) to wipe various drives in different circumstances. Depending on the speed and size of the drive, this process can take anywhere from 2 to 5 hours, and in our experience this is very reasonable for a 7-pass wipe.
Recently, we decided to update our tool/userspace/stack/thing (what this REALLY is is a PXE-booted Linux image of about 50 megs containing lots of different scripts, system probing/gathering utilities, etc.) and along with this shred was upgraded to 6.10. What we've noticed is that shred is approximately 5-6x slower than before in every case, and I'm not quite sure what has changed. I've checked the ChangeLog and I see that some changes were made with regards to the ISAAC code being divorced into a separate file, but I'm not entirely sure I have the familiarity to really dive into the code and track down what is going on, nor can I imagine any reason this change would have any effect on the speed of shred. My question is: is there anything that has changed substantially with the way shred works between theses two versions (which I admit is a 4year span) to result in such a difference? Is it conceivable that the old version was bugged, and working too quickly? Or perhaps the new version is bugged, and working too slowly? Or perhaps the new version is simply more sophisticated, generates better random numbers, and this is just the way it is? :) The difference, I'm sure, has to do with the way random numbers are being generated in each version, as the uniform passes run at equal speeds. Some data below: A "real" case, using a full /dev/sda wipe: 40GB PATA/SATA Hybrid Drive / 7 passes - Shred 5.2.1: 2.6hrs - Shred 6.10: 13.1hrs A "contrived" case, using a small 20MB dd'd image: 20MB (dd if=/dev/zero of=foo bs=1M count=20) / 7 passes: - Shred 5.2.1: 4.9s - Shred 6.10: 22.2s _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils