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

[Jay Ts]

Jeremy Allison (jra at dp.samba.org) wrote:
> 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).
> 
> Well we ship by default with the same options as
> Windows.

But, is that a good idea?  Sometimes, matching the
behavior of Windows is not for the best! ;-)
Certainly the extra 30% (?) performance is a nice
thing, and helps Samba get good reviews when compared
to Windows.  But I think we can agree that a policy of
matching the reliability of Windows is questionable.

I think what Chris is getting at (and I wince while
writing this, but I agree) is that it's better to
give priority to data integrity (as you've said),
and since many Samba users are now trusting Samba
servers with their database files, the default either
needs to be "oplocks = no", or to have very obvious
documentation somewhere where new Samba admins will
surely see it -- and this is not easy, considering that
Samba now comes bundled with all the popular Linux systems,
and other Unices as well.  And also considering that
the issue is not easy for Samba newbies (or even
"oldbies") to understand.

I know this is a tough issue, and I'm not sure what I'd
do if I were "in the driver's seat".  Perhaps as a
minimum, adding some documentation to the /docs directory,
as Chris suggests, and also putting lines in the example
smb.conf files showing how to turn off oplocks, and why.
Or maybe the example smb.conf files should turn them off,
with a comment explaining that the lines can be removed if
the Samba server isn't serving database files, and has good
network hardware, etc.

I should have said this much earlier: I think if everyone
is told straight out about this, then it will make life
much easier for Samba administrators, help magazine testing
labs _fairly_ compare Samba performance with that of Windows
(they can make sure to turn oplocks on before running the test),
and also make Microsoft look bad, as they should, IMO, since
they created this stuff.  Maybe it will pressure Microsoft
into disabling oplocks by default, and level the playing
field in favor of data integrity!

Jay Ts
author, Using Samba, 2nd ed.