oplock problem

[Johann Zuschlag]

Hello Robert,

>But I am still not save because the app manufacturer is not willing to
>provide a torture test that uses his DB and his libs. And we could not force
>the failure in a predictable way. So it is *impossible* to me to say:
>We solved it - yes.

>The only thing I can say is - the corruption did not occur again - until
>now.
>I am the consultant there and suggested to do at least daily backups.

>The settings I changed in /etc/smb.conf (we are using SMB 2.0.6 kernel
>2.2.16):

>   strict locking = yes
>   oplocks = False
>   oplock break wait time = 20
>   oplock contention limit = 4

The only important one is 'oplocks = False'. That stops the client from 
caching the database. Otherwise all writes to a database are kept in client 
cache until another client requests an oplock break which is not a good 
idea. In that case any changes to the to database would be lost in case 
one client crashes or a client misbehaves or due to network problems. 

Conclusion: Allways set oplocks = false if you have concurrent writes
to a database/file.

Or, if it is only one database file you could try 'veto oplock files'.

'strict locking' should be left to no (default).

Forget the other two.

>I was some disappointed that nobody of the specialists here in the list
>could
>help me out. I assumed that there would be at least one who could explain me
>if I am right in my assumptions what these params do.

Yes, you are right. :-)

Regards,

Johann