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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeremy > Allison > Sent: Wednesday, March 13, 2002 3:40 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> 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.
