Re: Default number of overwrites in shred

[Pádraig Brady]

HggdH wrote:
> On Mon, 2009-01-26 at 02:20 +0000, Pádraig Brady wrote:
>>> A consequence of this change -- right now -- is that all 3 passes
>> will
>>> be random. I am not sure if this was the intended result or not.
>> Yes we don't really care about the patterns written to file any more,
>> so random is as good as any. Attached is a test to make this explicit.
>>
>> cheers,
>> Pádraig.
>>
> 
> Thanks, Pádraig.
> 
> One more thing -- and please forgive me on insisting on this --: the
> random passes are done by using /dev/urandom, not by randomly selecting
> possible patterns from the passes table.
> 
> I did a quick & dirty test (and I am not suggesting this to be
> implemented, it was just to check), taking out two of the 'random'
> entries in the table. I then ran GIT shred, and my modified shred. This
> is what I get:
> 
> address@hidden:/tmp $ time shred --verbose test1.data
> shred: test1.data: pass 1/3 (random)...
> shred: test1.data: pass 2/3 (random)...
> shred: test1.data: pass 3/3 (random)...
> 
> real  0m5.761s
> user  0m0.016s
> sys   0m5.480s
> 
> address@hidden:/tmp $ time /usr/src/buildd/coreutils-git/src/shred
> --verbose test1.data
> shred: test1.data: pass 1/3 (random)...
> shred: test1.data: pass 2/3 (000000)...
> shred: test1.data: pass 3/3 (ffffff)...
> 
> real  0m2.430s
> user  0m0.020s
> sys   0m2.020s

Thanks for performance testing, showing reading /dev/urandom is the bottleneck.
I didn't want to change the "pattern" selection logic though.
If speed is of primary concern then I think one has enough control
with the --iterations and --random-source options already?

> May I suggest this to be revisited? If we do not care what type of
> passes we do, then we could just pick three out of all possible passes,
> and not force-feed random at least three times.

This will be revisited again anyway as per the TODO in the submitted patch.

cheers,
Pádraig.