Re: Default number of overwrites in shred

[HggdH]

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.

address@hidden:~/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
address@hidden:~/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
address@hidden:~/shred-test $ 

Regards,

..hggdh..

signature.asc
Description: This is a digitally signed message part