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: > > hg...@xango2:/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 > > hg...@xango2:/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. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
