shred is very slow

Thank you for opening this bug and helping make Ubuntu better.

Indeed. From coreutils 5.x to 6.0 shred moved from an internal PRNG to /dev/urandom (i.e., the system PRNG). It seems this move is most probably the reason for the new high time. I am trying to get some times from the execution of shred to confirm.

If this is indeed the case (and I think it is, but I am still to query upstream on that) I do not think there is much for us to do. Perhaps using Fortuna (see http://en.wikipedia.org/wiki/Fortuna_(PRNG)) as the PRNG might make a difference.

Thank you for reviewing my bug report.

A temporary stop-gap fix might be to pick a single value from /dev/urandom and use it for every write of the random pass, instead of picking a different value for every write.
Of course, every random pass must pick it's own value to strengthen the process.

I am unsure on the benefits of such a move: the idea behind writing the file/disk with random data is to make an eventual recovery more difficult. Fixing on a single value (albeit random) sort of defeats it -- it will be just a bit more difficult to find the pattern, and subtract it out of the signals.

Still researching.

Have you finished researching?

I ask, at least, to remove the "incomplete" status: as of 8.10 (fully updated) bug is still there, can be very easly verified by anyone and have a nice and elegant explanation, so this is all but "incomplete".

I am sorry. The day-to-day "earn money" piece took a toll on my available time to keep on here. By an amazing coincidence this was brought up at the upstream mailing list just a few days ago (see http://lists.gnu.org/archive/html/bug-coreutils/2009-01/msg00123.html), and it had a bit of movement today.

Previously we had http://lists.gnu.org/archive/html/bug-coreutils/2008-02/msg00318.html already pointing the current issue.

Anyway: I am going ahead and marking this as triaged, and will add in here the final position.

Thanks for your time and for the links: "--random-source=/dev/zero" is
the stop-gap trick that I was searching.

A recently committed patch to shred (coreutils trunk, 7.x) is reducing the default number of passes from 25 to 3. A quick and informal test shows a significant reduction in elapsed time. Nevertheless, all passes are now random.

Another recently committed patch upstream has taken out /dev/urandom as the default random source for shred (the internal PRNG is back in). shred is now at least 10 times faster.

I have opened (and marked fixed) an upstream task to signal a fix is available on current trunk.

This bug has been fixed on Karmic, coreutils 7.4.

A lingering issue is to recode the logic to select the overwrite passes (right now shred defaults to 3 passes, and all of them will be random). Nevertheless, there is no visible performance impact anymore.