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

[Chris de Vidal]

You hit it _on_the_nose_ here.  We wish someone had
commented in the smb.conf, the manpages, the
documents, ANYWHERE, about potential
corruption/slowness with large database files and
OpLocks.  There is a chance we would have been spared
grief.

/dev/idal

--- Jay Ts <jay at jayts.cx> wrote:
> 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.



__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/