This bug was originally found by Tim Wilkinson and Ben England. When trying to do sequential I/O (reads and writes) on a large file on a GlusterFS-based SMB share, we were getting unusual and unacceptably poor performance. On a lead from Ben regarding some odd locking behaviour, Raghavendra Talur and Anand Avati went digging and discovered a one-line smb.conf fix that seems to dramatically improve the performance in question: kernel oplocks = no Comparing against I/O on a large file on an XFS-based SMB share, we get the following numbers for the VFS/libgfapi Samba configuration (in contrast to the FUSE-based Samba configuration): WRITES: libgfapi is at ~85% of XFS (while FUSE is ~48%) READS: libgfapi is at ~78% of XFS (while FUSE is ~88%) We recommend implementing this configuration option right away in RHS.
In the original description, a simple one-line change to the smb.conf file is recommended. This change should have been handled in another BZ, so the change may already be in place. Please check to see whether the change is in place. If not, please add kernel oplocks = no to the smb.conf configuration. Gluster does not support oplocks, so this is the correct setting.
This fix is released as a part of RHS-2.1-20130806.n.0.
Verified on RHS-2.1-20130806.n.2-RHS-x86_64-DVD1.iso, the /etc/samba/smb.conf now has: # ------------------------ RHS Performance Tunings ------------------------- # # The following options improve RHS performance in the following respective # scenarios: # # - Large file sequential I/O # - Small file operations kernel oplocks = no stat cache = no #============================ Share Definitions ==============================
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1262.html