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@lineone.net]
Sent: Wednesday, February 06, 2002 11:37 AM
To: Noel Kelly; Russell Senior; jra@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@lineone.net]
>Sent: 06 February 2002 13:02
>To: Russell Senior; jra@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@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@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