https://bugzilla.novell.com/show_bug.cgi?id=668674
https://bugzilla.novell.com/show_bug.cgi?id=668674#c3
--- Comment #3 from Ralf Friedl 2011-06-28 17:59:08 UTC ---
This performance-related problem is exactly the reason why this should be
changed.
It is exactly as you describe in the Samba bug report:
The owner of a file can get the oplock, another user can't. The consequence is
that the owner of the file will get the oplock, request a reasonable sized part
of the file and feed it to the application on the client, without any calls to
the Samba server.
A different used doesn't get the oplock and will therefor request every single
read from the Server. Now some application call read for just a few bytes, so
it can take really long to read files of moderate size.
(Interestingly, some Windows clients seem to ignore this oplock failure and
cache the file anyway, so they don't see performance problems.)
This is exactly what can be seen in the logs you provided in the bug report:
Oplock refused because the process is not the owner of this file. The answer
there is just a little incorrect, because it's not a kernel problem, it's the
documented kernel behavior. Samba contains code to work around that, the
mentioned libcap code, that is just disabled in Suse Samba. That is most likely
the reason why the samba developer wrote WORKSFORME.
I can always build my RPMs with libcap enabled, now that I know what to look
for, but I think other users would also like to have a fast Samba server
without compiling their own Samba or disabling kernel oplocks.
If you want to know about possible drawbacks of this change, the Samba
developers should know about that.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.