At 01:05 PM 2/15/2005, you wrote:
>I'm not going to claim I truly understand how /dev/random works, let alone
>how
>it can be improperly configured. However, I wonder if the misconfiguration
>can be detected programatically?
The /dev/random driver waits for unpredictable system events to
occur, i.e. timings between certain hardware interrupts. (This
is why software like PGP will instruct the user to move the mouse
around or type some keys while the random number is being generated.)
If not enough events occur, then /dev/random will block and the
application has to wait.
On BSD systems, there is a command-line tool for configuring the
device, whereas in Linux it's controlled from /proc/sys/kernel/random/.
A "bad" configuration just means that it takes longer than necessary
to generate random numbers. Of course, this only matters if there is
significant application for the "limited resource".
A second issue to consider is that on Linux 2.4 kernels, /dev/urandom
shares the same "entropy pool" as /dev/random. This is a problem
because /dev/urandom is supposed to be an "unlimited" resource, but
on the 2.4 kernel it indirectly depletes /dev/random. In our case,
/dev/random (and thus Subversion) was infinitely blocked as a result.
>In other words, is it possible to modify the Subversion or APR
>configure scripts to look for this situation and default to
>/dev/urandom if it appears necessary?
My opinion is that it is a mistake for APR to ever use /dev/random.
In an ideal configuration /dev/urandom is just as good, and even
if you could make some case that the degree of randomness matters
(which I would dispute), I cannot see how "Subversion really slow"
is an acceptable user experience.
If anything, this is an APR bug that should be reported to the
Apache people. But for Subversion's purposes, we can just fix
the default APR configuration.
Cheers,
-Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 15 20:51:58 2005