Fix for multi-user database corruption problems just checked in.

[Gerald Drouillard]

I finally got a chance to stress test a 2.2.4 with my netperf program
(clipper against FoxPro databases).  The default lock spin time/count
settings worked fine for 2 workstations.

For 6 workstations I changed:
lock spin time =15
Anything higher OR lower (by 5's) makes the server load increase and reduces
performance on the workstation

lock spin count =50
This value does not effect performance, but is required to get the machines
to complete the test without GPF'ing.  I found no reason not to be generous
with this setting.

Regards
-------------------------
Gerald Drouillard
Owner and Consultant
Drouillard & Associates
http://www.Drouillard.ca


> -----Original Message-----
> From: samba-technical-admin at lists.samba.org
> [mailto:samba-technical-admin at lists.samba.org]On Behalf Of Jeremy
> Allison
> Sent: Wednesday, March 13, 2002 3:40 PM
> To: samba-technical at samba.org
> Cc: jra at samba.org
> Subject: Fix for multi-user database corruption problems just checked
> in.
>
>
> Hi all,
>
> 	I discovered something today. I was given a test
> prgram by "Gerald Drouillard" <gerald at drouillard.ca> that
> allowed me to completely reproduce foxpro database corruption
> to a Samba 2.2.3a server - guarenteed.
>
> Ths same program did not fail when run against a W2K
> server.
>
> It was complaining about lock violations. Now Andrew's
> smbtorture lock tester does a *complete* test of
> our locking code against W2K and we pass as identical,
> so I really doubted that we were getting the lock
> semantics wrong, especially as these were very simple
> lock requests.
>
> One strange thing with the lock tests though - Samba
> is *much* faster at completing the smbtorture tests than Windows
> 2000 - which made me start to wonder.
>
> So I did some digging.......
>
> It turns out that when a Windows client asks for a lock,
> and tells the server that the timeout is zero (ie. don't
> wait to get the lock, just check *right now* to see if
> you could get it), then a W2K server seems to do a very strange
> thing. It apparently *spins* for a short time trying to get the
> lock - it *doesn't* respond immediately ! Samba wasn't doing
> that.
>
> And of course :-), the Foxpro database code seems to be dependent
> on this behavior.
>
> I have just added some code to Samba (SAMBA_2_2 and HEAD)
> to force Samba to spin a parameter dependent number of times
> and also to usleep a parameter dependent time between attempts.
> Currently I have these set to 3 spins and 10usecs.
>
> When I do this the test program passes *perfectly* against
> a SAMBA_2_2 CVS and HEAD server.
>
> So, for people whe are experiencing MS Access and Foxpro
> database corruption problems I'd appreciate it if you
> could check this new code out and test it - I think this
> is the answer (it also fully explains why W2K is so slow
> on the lock tester as well :-) to fix the database corruption
> problems.
>
> Let me know.....
>
> Jeremy.