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

[David Brodbeck]

> -----Original Message-----
> From: Green, Paul [mailto:Paul.Green at stratus.com]

> My opinion is that the "right fix" is for anyone who is 
> experiencing data corruption of any sort, whether with oplocks on, off, or

> sideways, to work with the Samba team to come up with a reproducible test
case 
> so that we can root cause the true source of the problem.  Then, we can 
> design and test some sort of fix, and no one else will ever have to worry
about it.

What I'm seeing from the Samba team is "this is a Windows client bug" or
"this is an MS Access bug".  I'm not saying they're wrong, but if that's the
conclusion that's been reached wouldn't the rest of us just be wasting our
time by trying to test this?  The consensus seems to be that oplocks with
Windows clients are simply broken by design.

FWIW, I've never seen any corruption I could blame on Samba, with oplocks
on, but my site only has 30 users, tops, and the most we ever had using the
Access database simultaneously was five or six.  (I did turn kernel oplocks
off a couple months ago, but only because we don't need them -- nothing gets
accessed from the UNIX side except during backups.)  We actually saw more
corruption in the Access database under Windows NT, but I blame this on a
user who had a bad network connection that we discovered about the time we
switched to Samba.  This would tend to back up the theory that dropped
packets aggravate this problem.  It's rather shocking to me that SMB reacts
to poorly to network problems, but I realize there's not much Samba can do
about the crummy protocol design. ;)