[Samba] Re: Samba 2.2.3 Oplock problem...

[David Brodbeck]

My experience sort of parallels this...we had mistakenly put one of our
Access and AutoCAD users on a 10baseT hub that was badly overloaded and
dropping a lot of packets, and we had all kinds of locking-related problems.
We moved him to a 100baseT switch, and all the problems went away.  We
haven't had a single problem with Access or AutoCAD since, even though
oplocks are enabled system-wide.

So in my experience the oplock code *can* work quite well, but you'd better
have a tightly-run network.  It won't abide poor network performance.  I'm
not sure this is strictly a Samba problem, either -- Access had been acting
up on the NT server as well, though AutoCAD didn't seem to.

-----Original Message-----
From: Martyn Ranyard [mailto:ranyardm at lineone.net]
Sent: Wednesday, February 06, 2002 11:37 AM
To: Noel Kelly; Russell Senior; jra at samba.org
Cc: Samba Maillist (E-mail)
Subject: RE: [Samba] Re: Samba 2.2.3 Oplock problem...

Whilst I cannot say one way or another on a tight network, because in 
theory it can slightly speed things up if say the program locks a record, 
and unlocks it, that kind of thing is never passed to the server if no 
changes are actually made.  On a leaky network you are definitely right and 
when especially when M$ Access is used, because M$ wrote it so that it 
would use oplocks heavily and that just shows up the bad behavior of such 
predictive coding.


>Thanks for your insight.
>Noel
>
>-----Original Message-----
>From: Martyn Ranyard [mailto:ranyardm at lineone.net]
>Sent: 06 February 2002 13:02
>To: Russell Senior; jra at samba.org
>Cc: Samba Maillist (E-mail)
>Subject: Re: [Samba] Re: Samba 2.2.3 Oplock problem...
>
>
>
>I remember a talk at our lug about oplocks,  If I remember correctly then
>the following is true :
>
>A client takes the file, caches it at client side, and oplocks it.
>The server then gets a different request to read the file, asks the client
>to send it's latest version.
>Here, two things can happen, 1. the client responds with changes, which the
>server reflects or 2. the client doesn't respond in time, in which case the
>server breaks the oplock and reverts the file to it's unchanged
>state.  This is the way SMB oplocks work AFAIK
>
>Network problems can cause delays and therefore timeouts will timeout (it
>is their job, afterall).  This is why leaky networks cause oplock problems.
>
>I contribute this hazy knowledge to the public domain, mainly to save
>Jeremy some time!
>
>At 08:59 AM 2/5/02 -0800, Russell Senior wrote:
> > >>>>> "Jeremy" == Jeremy Allison <jra at samba.org> writes:
> >
> >Jeremy> Most oplock problems are due to bad network setups (client
> >Jeremy> drivers, hubs etc). I haven't seen any evidence other than one
> >Jeremy> person having oplock problems (which is not unusual given the
> >Jeremy> state of many networks) that this is anything other than the
> >Jeremy> usual network related oplock woes.
> >
> >Can you elaborate on this?  As I understand it, the oplock break
> >messages are getting lost, but aren't they sent over the TCP socket?
> >Won't the regular TCP reliability guarantees ensure it gets resent if
> >not ACK'd?  How can network problems interfere?
> >
> >
> >--
> >Russell Senior         ``The two chiefs turned to each other.
> >seniorr at aracnet.com      Bellison uncorked a flood of horrible
> >                          profanity, which, translated meant, `This is
> >                          extremely unusual.' ''
> >
> >--
> >To unsubscribe from this list go to the following URL and read the
> >instructions:  http://lists.samba.org/mailman/listinfo/samba
>
>==============
>Martyn Ranyard
>
>
>--
>To unsubscribe from this list go to the following URL and read the
>instructions:  http://lists.samba.org/mailman/listinfo/samba
>
>--
>To unsubscribe from this list go to the following URL and read the
>instructions:  http://lists.samba.org/mailman/listinfo/samba

Martyn

Life's a bitch, but so am I.


-- 
To unsubscribe from this list go to the following URL and read the
instructions:  http://lists.samba.org/mailman/listinfo/samba