Fixed: OpLocks caused the corruptions/slowness (Was: How Samba let us down)

[Jay Ts]

Chris de Vidal wrote:
> 
> Still, wouldn't you welcome documentation advising
> people of potential corruption?  I think we both agree
> that there is no guarantee that everyone's network is
> 100% "on" and the danger of corruption appears to be
> greater when there are large files read and written to
> a record at a time (namely, flat databases).

I agree, and am getting together a better explanation
of this problem to write up in Using Samba.  (Hopefully,
this will make it into the 2nd edition.)

I was thinking of making the point that when oplocks
are enabled, the client is really trusted to cache
the file, and send back the updates when it receives
the oplock break request.  The integrity of the data
is then much more dependent on the client working
properly than in the non-oplock scenario.  Since
the clients are generally Windows systems, it should
be understood that using oplocks carries an inherent
additional risk for data integrity.

Jeremy: does this sound ok? Or is it a little to
cautious? And, if a (Windows) client is holding
an oplock and it crashes or malfunctions, does that
have the same effect as ignoring an oplock break
request?  Or is it worse?

(I will also add a note saying that Samba is
no different than Windows in its default behavior.)

Jay Ts