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

[Neil Hoggarth]

On Thu, 24 Oct 2002, Chris de Vidal wrote:

> I'd be happy to let the group know.  I'm not positive
> we'll reenable anything but kernel oplocks, though.
> We have work to do.

The "kernel oplocks" parameter affects how Unix processes accessing the
file interact with SMB oplocks. Enabling kernel oplocks on a share which
doesn't have SMB oplocks turned on shouldn't make any difference, I'd
have thought.

If I understand your description correctly you don't have Unix processes
interacting with the stored files; your Linux box is acting purely as an
SMB file server for Windows clients? All the file accesses come in from
the net, via Samba? In this case you probably want to leave kernel
oplocks off ('cos they buy you nothing, functionally, and there have
been suggestions that Linux kernel bugs causing problems with them). The
interesting test is whether either of:

	oplocks = yes
	level2 oplocks = no

or

	oplocks = yes
	level2 oplocks = yes

work.

If your corruption returns *and you can show that your network and
clients are working properly* (ie. no oplock break messages are getting
lost or being ignored by client machines - which probably requires
Ethernet packet captures) then it's probably "Red Alert" time.

Also: don't think that if you establish the existence of a priority 1
bug then it is all over - if you're experiencing a bug that the team
can't reproduce themselves then it doesn't mean that there isn't a bug,
but it does mean that they're going to need a lot of help characterizing
and finding it.

Regards,
-- 
Neil Hoggarth                                 Departmental Computer Officer
<neil.hoggarth at physiol.ox.ac.uk>                   Laboratory of Physiology
http://www.physiol.ox.ac.uk/~njh/                  University of Oxford, UK