samba - Dec 2001 - Locking problems in 2.2.2

Hi, 

I am using a small network of, say, 10 W2K workstations on which I run a 
database application using shared table and index files on a Samba 2.2.2 server 
(Suse Linux 7.2). The application was just ported from Clipper to XBase++. The 
Clipper compiled app (it's a 16-bit DOS application) runs fine. The 32-bit
XBase++
app produces corrupt index files and behaves eratically after several minutes 
under normal workload. Of course I was blaming the XBase++ compiler first. I 
then tried playing around with the locking settings in smb.conf, trying to set 
Samba to what I thought would be the least aggressive configuration (oplock OFF,
blocking locks OFF, strict locking ON and so on). Besides Samba beeing slower it
didn't effect he problem in any way.

I made the following observations:

a)  At times, using the XBase compiled app, the index files would get huge. 
    Their size would be around 2 Gigs. The lock offset for index files is 2 Gigs
    plus the record offset.

b)  I have a little utility program which I use for managing the database. This 
    program is a Clipper-compiled 16-bit DOS app. Usually, I cannot use that 
    utility when the main application is using the files. This is because the 
    utility opens the file in exclusive mode. To my surprise I *was* able to 
    open the database in the 16-bit utility even while the 32-bit XBase++ 
    compiled main app was using it!
    
c)  In my desparation I moved all the files to a spare W2K server and the 
    problems went away! I didn't have time to try previous versions of
Samba.

d)  I have seen more messages in this list reporting 2.2.2 problems regarding 
    corrupted index files and record locks.
    
What should I try next? I would really like to continue using Samba as my main 
file server. BTW: both, the W2K server and the workstations are service pack 2.

Regards

-- Hannes

On Sun, Dec 02, 2001 at 04:01:58PM +0100, Hannes Schmidt
wrote:
> Hi, 
> 
> I am using a small network of, say, 10 W2K workstations on which I run a 
> database application using shared table and index files on a Samba 2.2.2
server
> (Suse Linux 7.2). The application was just ported from Clipper to XBase++.
The
> Clipper compiled app (it's a 16-bit DOS application) runs fine. The
32-bit XBase++
> app produces corrupt index files and behaves eratically after several
minutes
> under normal workload. Of course I was blaming the XBase++ compiler first.
I
> then tried playing around with the locking settings in smb.conf, trying to
set
> Samba to what I thought would be the least aggressive configuration (oplock
OFF,
> blocking locks OFF, strict locking ON and so on). Besides Samba beeing
slower it
> didn't effect he problem in any way.
> 
> I made the following observations:
> 
> a)  At times, using the XBase compiled app, the index files would get huge.
>     Their size would be around 2 Gigs. The lock offset for index files is 2
Gigs
>     plus the record offset.
> 
> b)  I have a little utility program which I use for managing the database.
This
>     program is a Clipper-compiled 16-bit DOS app. Usually, I cannot use
that
>     utility when the main application is using the files. This is because
the
>     utility opens the file in exclusive mode. To my surprise I *was* able
to
>     open the database in the 16-bit utility even while the 32-bit XBase++ 
>     compiled main app was using it!
>     
> c)  In my desparation I moved all the files to a spare W2K server and the 
>     problems went away! I didn't have time to try previous versions of
Samba.
> 
> d)  I have seen more messages in this list reporting 2.2.2 problems
regarding
>     corrupted index files and record locks.
>     
> What should I try next? I would really like to continue using Samba as my
main
> file server. BTW: both, the W2K server and the workstations are service
pack 2.
This is due to the differences between set allocation, and
set end of file, which were not properly separated in Samba 2.2.2.

I think we've fixed this (along with many other bugs) in the
current SAMBA_2_2 CVS tree. If you'd test this for us to see
that the latest code fixes your problems and report back I'd
appreciate it, as it will ensure the 2.2.3 release containes
fixes for your problem.

Thanks,

	Jeremy.