samba - Jan 2001 - Samba 2.0.7 slowdown on Solaris 2.6 with gigantic /dev tree

Hello,

Please apologize, if this has been raised before. I didn't find any hint for
this problem before.

I've used gcc 2.8.1 and installed Samba 2.0.7 on a Solaris 2.6 machine.
At start of smbd I notices a huge slowdown: about 5 minutes for each new
login!

The explanation: Solaris doesn't have a /dev/urandom device and therefore
Samba tries to get a random seed by scanning /dev and xor-ing the inode
values. But the machine has about 60000 device entries in /dev (because we
have lots of storage attached to the server), so this resulted in this
unpleasant behaviour.

I've attached a patch which just replaces /dev with /tmp in
"source/lib/genrand.c". Maybe it is better to scan only some fewer
/dev
devices or to make a configuration option for the used directory.

Is this a known problem? It still exists in Samba 2.2.0-alpha1.

Bernhard 

PS: I am not yet on this list. Please Cc any replies.

-- 
Bernhard Sadlowski,             fon: +49 5241 80 88558
Mohn Media GmbH                 fax: +49 5241 80 6628
sat06@mat.mohn.bertelsmann.de	
-------------- next part --------------
diff -ur samba-2.0.7/source/lib/genrand.c
samba-2.0.7-devfix/source/lib/genrand.c
--- samba-2.0.7/source/lib/genrand.c	Wed Jul 21 03:25:08 1999
+++ samba-2.0.7-devfix/source/lib/genrand.c	Thu Jan 25 18:36:47 2001
@@ -140,8 +140,11 @@
   if(!got_random) {
     /*
      * /dev/urandom failed - try /dev for timestamps.
+     *
+     * source changed for solaris systems, which have gigantic /dev trees
+     * use now /tmp instead of /dev
      */
-    do_dirrand("/dev", md4_inbuf, sizeof(md4_inbuf));
+    do_dirrand("/tmp", md4_inbuf, sizeof(md4_inbuf));
   }
 
   /* possibly add in some secret file contents */

Bernhard Sadlowski wrote:
| I've used gcc 2.8.1 and installed Samba 2.0.7 on a Solaris 2.6
machine.
| At start of smbd I notices a huge slowdown: about 5 minutes for each
new
| login!
	
	Erk! we shouldn't do this for every login!
	And we arguably should have a limit on the
	number of nodes scanned, anyway.

	The code in uint32 do_reseed says:
 We use /dev/urandom as a read of /dev/random can block if
 the entropy pool dries up. This leads clients to timeout
 or be very slow on connect.

	I'd suggest adding an integer counter and a 
	limit to do_dirrand: in place of 
		while ((p = readdirname(dp)))
	just put in
		for  (i=0; p = readdirname(dp) && i < XXX; i++) 

	A side comment: the size of items in a Solaris /dev
	clusters around 25 characters, and so isn't a really
	good source of randomness.

--dave
-- 
David Collier-Brown,           | Always do right. This will gratify 
Performance & Engineering Team | some people and astonish the rest.
Americas Customer Engineering  |                      -- Mark Twain
(905) 415-2849                 | davecb@canada.sun.com