On Sun, 10 Aug 2014 10:50:42 -0400 Gary Dale <garyd...@torfree.net> wrote:
> Your results... The test was only a very simple comparison. If you want a more thorough test, it's certainly much better to break everything out the way you have listed... and it's probably best done on the chosen and completed hardware configuration. However, everything was completed on the same cpu, with the same drive, and same resources. This means that - the disk i/o is constant, since the drive and controller are the same. So, logically, the main difference /must/ be cpu time. I'm not arguing for or against any particular bit-rot testing mechanism - just that given uniform drive parameters, various methods of verifying file data integrity are limited by cpu time. This should also be obvious from the math required to do the various crypto and data checks... As far as par creation goes -- it's obviously going to take a long time... that's why you want to do it less often, and in a scheduled way. md5 https://en.wikipedia.org/wiki/MD5 sha1 https://en.wikipedia.org/wiki/SHA-1 par https://en.wikipedia.org/wiki/Reed-Solomon_error_correction It can easily be seen, even by a non-expert, looking at the summary box explanation that comparing md5 with sha1... sha1 would be much slower. It's harder to compare reed-solomon in a pseudo direct way --- but it is slower... This is not a design error. It's actually what is desired. The slower a crypto scheme functions, the 'better' it is... Of course, this is a generalized non-expert statement. However, it can be imagined that the goal is to slow down an attacker to a speed that requires so significant a time requirement that brute forcing would be effectively impossible. On the par checking, it's based on sampling and correlation. All of these mathematical calculations are done in the cpu. So, if you have a system with enough RAM to hold large files -- the limiting factor will be cpu time, cpu resources, and program structure -- i.e. does the program use the processor effectively, with threading and properly filled registers... --Andrew -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140810113508.e3c0f0637a23f1765c61b...@1024bits.com
