fcntl F_SETLKW64 failing on Solaris

[Mayers, Philip J]

Interesting, I did notice that constant - I thought that the tdb traversal
of several (e.g. the locking database) was intentional. Won't this cause
dead PID TDB records to build up?

Regards,
Phil

+------------------------------------------+
| Phil Mayers                              |
| Network & Infrastructure Group           |
| Information & Communication Technologies |
| Imperial College                         |
+------------------------------------------+  

-----Original Message-----
From: jra at samba.org [mailto:jra at samba.org]
Sent: 14 January 2002 19:32
To: Mayers, Philip J
Cc: 'jra at samba.org'; David.Collier-Brown at Sun.COM; Romeril, Alan;
samba-technical at samba.org
Subject: Re: fcntl F_SETLKW64 failing on Solaris


On Thu, Jan 10, 2002 at 08:04:09PM -0000, Mayers, Philip J wrote:
> 
> The only solution I can think of is to move the tdb_traverse of the
various
> locking and connection TDBs into a periodic scan made from either a
watching
> process or the listening smbd (in daemon mode). This should reduce the
load
> somewhat, and IIRC was already suggested a month or so back. Sadly, I have
> neither the time to make nor the ability to test such large changes...
> (there's always one, isn't there :o)

This email triggered me to look closely at the claim_connection code
in smbd. NB. All the traversals on startup in the locking and share
mode db's have been removed in the latest CVS code.

I discovered something very stupid..... in include/local.h the variable
MAXSTATUS was set to 100000, whereas the code in smbd/connection.c looks
for the value *zero* to stop the tdb traversal.

This was a holdover from old Samba 1.9.x code - I have now fixed this
in 2.2.x and HEAD CVS trees so that MAXSTATUS is removed, and zero means
infinite connections.

This will stop any tdb traversal of the connections tdb on smbd
startup, and should mean no smbd does a traversal of any tdb on
startup.

This may have been the last missing piece in the Solaris puzzle....

DaveCB & all, can you please checkout this change and kick the c*$p
out of it in stress testing on big Solaris servers .... :-) :-).

I'm hoping this will fix it (fingers crossed). This was my last
showstopper 2.2.x bug.... !

Jeremy.