Re: par2
On Sun, 10 Aug 2014 10:50:42 -0400
Gary Dale <garydale@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
Reply to: