Try the following:
socket options = TCP_NODELAY SO_SNDBUF=65536 SO_RCVBUF=65536
IPTOS_LOWDELAY
use sendfile = no
lock spin time = 15
lock spin count = 100
oplocks = no
level2 oplocks = no
You may have to tune your smb settings to get foxpro to perform
Oplock's tells the Windows Client he can cache the requestet file on
local machine.
Should the Client change the File (or another Client would do this) the
Lock must released by the first Client, or Samba break's the Lock after
a certain time he doesn't become the Lock back.
When you take the
Oplock's tells the Windows Client he can cache the requestet file on
local machine.
Should the Client change the File (or another Client would do this) the
Lock must released by the first Client, or Samba break's the Lock after
a certain time he doesn't become the Lock back.
When you take the
What Version of Samba is running?
Various versions of 3.0 on multiple servers.
Is it a kind of Locking Problem?
Ooh, good question, I'm not sure, and I'll try your oplocks settings.
What exactly am I turning off, however, if I do that? Am I turning off
file locking altogether?
What speed
Whoops, I guess I didn't reply correctly and accidentally created a new
thread with my response, so here's to hoping I get it right this time...
What Version of Samba is running?
Various versions of 3.0 on multiple servers.
Is it a kind of Locking Problem?
Ooh, good question, I'm not sure,
You should be able to do a crude test by creating a large file (dd
if=/dev/random of=test.dat bs=1048576 count=100 will create a 100MB
test file) and then timing how long it takes to read the file back
(time dd if=test.dat of=/dev/null) That'll tell you if your hard
drives are configured
Ok so maybe someone can explain this to me. I've been banging my head
against the wall on this one for several weeks now and the powers that be
are starting to get a little impatient. What we've got is an old FoxPro
application, the FoxPro .dbf's being stored on a Linux fileserver using
Samba