problem with oplocks.

[Michael B. Allen]

On Mon, 17 Feb 2003 15:02:59 -0600
"Christopher R. Hertel" <crh at ubiqx.mn.org> wrote:

> On Mon, Feb 17, 2003 at 02:53:14PM +0100, Olaf Fr?czyk wrote:
> > On Mon, 2003-02-17 at 14:42, Ireneusz Piasecki wrote:
> > > Hi.
> > > 
> > > I use samba with linux 7.2 kernel 4.7, samba 2.2.1a
> > 
> > > Is there any solution to avoid these errors ??
> > > 
> > > With redhat 6.2 and samba 2.0.2 (?) tehere were no errors.
> > > 
> > Hi,
> > 
> > I had the same problems. Upgrade your samba to 2.2.7a and it will work
> > OK.
> > It was fixed about 2.2.6 AFAIK.
> > BTW, oplocks are unreliable by definition, so I don't use them.
> > The small speed improvement (if any) is not worth loosing data integrity
> > from my point of view.
> 
> Um... Just curious, but how are "oplocks are unreliable by definition"?

I wondered what was meant by this too. I concluded it was just a zealous
choice of words. I believe he means that a) even after being granted an
oplock break the client may still find the file is locked and ultimately
get a sharing violation and b) on any system other than Windows or systems
with kernel oplocks the file can still be written to and possibly c)
if the oplock holder looses connectivity and another writer commits
changes data will be lost. There's nothing unreliable or technically
flawed about the protocol though. NFSv4 will have the same issues.

Mike

-- 
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and, more important, to tasks that have not
yet been conceived.