oplock problem

[Rick Rambo]

Robert

Our box is an Intel RH6.2 (2.2.14 kernel) with samba 2.0.6.  We have set up
shares which are used in two different ways; (1) User/home shares and (2)
Library
shares.

The "user" shares seem to operate just fine files can be copyed/moved,
apps (MS Office, AutoCad, etc) can open these files and edit them with no
apparent problems.

The "library" shares all are accessed by a software called "Revision Master"
a small document/file management system.  The software maintains a database
of revisions to the files it stores in a directory structure.  These files
are stored in a compressed format.  We moved this application from an
existing WinNT 4.0 system.

Performance of the library drops to nil if you can open the database at all,
new files cannot be added, and  update operations can cause random data
corruption.

The vendor of the software is no help, it appears they my be dropping the
product before long. So I will be shopping for a new library package
sometime next year.  Until that time however I'm stuck with what we have.

Like your situation I can find no predictability in the corruption.
Sometimes (very seldom) it functions flawlessly.  I have yet to browse the
source, I really don't want to go that route but will make the time if need
be.

I assumed originally that I was having permission problems.  Reseting the
file system and share perms to 0777 hasn't changed things.

For the time being I have moved the library back to a NT box and am testing
on a copy.  I will implement the oplock settings and see what happens. I'll
let you know.

I would assume there are more than a few people using applications which
perform similar disk/file operations, but they haven't seemed to surface on
this list.

Rick

> -----Original Message-----
> From: Robert Schott [mailto:rschott at schott-memsys.com]
> Sent: Wednesday, December 06, 2000 12:45 AM
> To: Rick Rambo
> Cc: samba at samba.org
> Subject: RE: oplock problem
>
>
>
>
> > I was wondering if you had solved your data corruption
> > problem in samba?  I seem to have a similar problem and have
> > not found a solution in the samba mailing list or archives.
>
>
> Hello Rick,
>
> for several days there occured no more fault (exactly since last friday
> morning).
>
> 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
>
> This is placed in general section of smb. I wanted to be safe that smb
> is configured this way. I don't want to make experiments on a live system.
>
> I did some tests from a single workstation copying about 100 MB to smb
> server
> and found no influence in performance. That params seem really to hit the
> locking. So it will switch on *conservative* settings (again - I
> still guess
> if I am wrong).
>
> There is a file speed.txt in /usr/doc/packages/samba that
> explains some but
> not all. And I must admit that I am not that perfect when it comes to
> reading
> C sources implementing SMB.
> Ok maybe I should try it - but the time factor - you know... ;-)
>
> 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.
>
> I hope the things above may give hints and do help. Maybe one of the
> mentioned
> above finds now it is worth to tell us if I am right? Maybe you
> could e-mail
> me your experiences?
>
>
> Robert
>
>
>
> Robert Schott
> roottec.com
>
>
> -----------------------------------------------
> security is an illusion
> (Bombolo)
>
>
>