On Mon, 2009-01-26 at 16:42 +0000, Pádraig Brady wrote: > > Please keep in mind I have not yet run a real performance test > (multiple > > runs, multiple file sizes). > > Yes cache may bias the results somewhat, though /dev/urandom is > surprisingly slow: > > $ dd bs=1M count=100 if=/dev/urandom of=/dev/null > 100+0 records in > 100+0 records out > 104857600 bytes (105 MB) copied, 23.3218 seconds, 4.5 MB/s >
I would expect this behaviour. /dev/urandom has to have enough entropy to produce a random value; if it is low on entropy, then it may take longer to generate a new value (I have seen this on extremely busy HTTPS servers -- the symptom was a quite long time to negotiate SSL/TSL session opens). Using /dev/urandom to provide values for shredding very large files will certainly put a time penalty on the PRNG: after all, we are making extremely fast, massive, requests for random values. This is why I have been insisting on this. Reducing the number of default passes certainly significantly lowers the elapsed time of a shred run; reducing the number of random passes will still have yet another significant lowering on the elapsed time. (I dimly remember the Linux PRNG implementation changing in order to provide a faster response, but I do not remember the details.) Below I have two runs of 'dd', one using /dev/zero, and one using /dev/urandom, similar to yours (so that we have a baseline). Although I was expecting usage of /dev/urandom to be quite slower, I am really surprised on how much it was. hg...@xango2:~/shred-test $ dd bs=1M count=100 if=/dev/zero of=/dev/null 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 0.146367 s, 716 MB/s hg...@xango2:~/shred-test $ dd bs=1M count=100 if=/dev/urandom of=/dev/null 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 20.3969 s, 5.1 MB/s hg...@xango2:~/shred-test $ Regards, ..hggdh..
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
