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

[Martyn Ranyard]

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