[Samba] Samba + Clipper

[Jim Morris]

On Friday, November 29, 2002, at 05:43  AM, Riviera Adm - Marcelo 
Oliveira da Costa wrote:

> Then we turned off oplocks and level2oplocks and found peace.
> But sometimes the system until freeze in one station and this freeze 
> others stations too.
> When clipper system is closed in the first freezed station, the others 
> return to normality.

This sounds like a locking issue.  What locking related options do you 
have set in smb.conf?

Also consider the possibility of a network hardware issue (bad network 
card, bad cabling, bad hub).  Test performance using a tool like a 
'flood ping' on your Linux server to some of the problem clients. As 
root, run 'ping -f x.x.x.x' and see what percentage of packets (if any) 
are dropped after you let it run a little while. Press Ctrl-C to stop 
the test....

I use dBASE files that are several hundreds of MB's in size (total size 
of almost 1GB in about 8 dBASE tables).   Application performance is 
acceptable on both 10BaseT and 100BaseTX LAN segments - although you 
can notice a difference on the 100Mbps segments certainly.

Locking options I use are:

locking = yes
strict locking = yes
share modes = yes

Note that you can turn off oplocks for JUST the DBF/MDX/NDX files using 
the 'veto oplock files' option in your smb.conf, on a per-share basis. 
For example:

[sharename]
     veto oplock files = /*.DBF/*.dbf/*.MDX/*.mdx/

> The softhouse that was developer clipper system say:
>  
> * linux and samba is the problem
> > he don't know nothing about linux

He is wrong on that point - I've been using Samba for dBASE file 
storage since 1994....

> * network bandwidth is the problem [100 and 10 Mbit/s]
> > maybe ...

That depends on what type operations you are doing. I have seen decent 
performance on 10BaseT LAN segments for indexed lookups on DBF files 
that were 200-300MB in size.  Writes can take longer though, as when 
you append a record, the index update may require rewriting the index 
file on the server.

> * server is the problem [ Compaq ML330G2 : PIII 1GHz, 256, 18GB SCSI, 
> 100Mbit/s only file server for 33 clients ]
> > I don't believe in this ...

The server is not an issue, as long as its disk performance is able to 
sustain the network bandwidth.  CPU is usually not a factor. I have a 
dual PII-400 and a Pentium 100MHz still in active operation as Samba 
servers.....

 
> Our major DBF has 65MB and the major NSX has 18MB.
> I think that is big and the problem is it,  but system developer say 
> that isn't.

It is big, but not too big. It really depends on how the application is 
written, and how it updates the data tables and indexes....
 
> I don't want to come back to NT4, where the clipper system too crash.
>  
> Resume: Where I can find information about samba and clipper systems ?

Good luck - there will not be too much info. We migrated most of our 
DOS based clipper applications to C++ applications for DOS and Windows 
years ago.....   Even in that environment, not too much developer 
support is available these days.

Good luck with your problem.

  --
Jim Morris (Jim at Morris-World.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4206 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba/attachments/20021129/a4b28a67/attachment.bin