Fixing slow samba shares
 

Hi all ,

In my office we are having 4 Debian squeeze machines , in these machine we set up samba shares , but accessing these shares from windows machines was far too slow. I googled to find out the solution as

Open up /etc/samba/smb.conf

Add the following to the ‘[global]‘ part of the config:

socket options = TCP_NODELAY SO_KEEPALIVE SO_RCVBUF=17520 SO_SNDBUF=17520 IPTOS_LOWDELAY

Add the following to the ‘[share]‘:

delete readonly = yes
oplocks = yes


now can any one explain the terms:- IPTOS_LOWDELAY , oplocks etc ?

These settings are all explained in the Samba documentation, available on samba.org.

TCP_NODELAY shouldn't be necessary, as it's been the default since Samba 2.0.4. It actually causes Samba to send multiple, smaller packets to minimize the time it has to spend waiting for TCP acknowledgements from the client.

SO_KEEPALIVE causes Samba to do periodic keepalive checks to verify that clients with open connections are still reachable, and then purge connections to non-reachable clients. This should not directly affect performance, but may free some resources in environments with a large number of clients.

SO_RCVBUF and SO_SNDBUF sets the size of the receive and send buffers respectively. A larger buffer may result in somewhat higher performance, but most Samba tuning documents refer to this increase as "marginal".

IPTOS_LOWDELAY has to do with the "Type of Service" field in IP packets. Specifying IPTOS_LOWDELAY means the OS, if it supports IP ToS, will move these packets to the front of the queue, ahead of any packets not marked with "LOWDELAY". Since TOS is an actual field in the IP header, routers supporting IP TOS will do the same.

delete_readonly simply allows deletion of read-only files from directories where the user has write permissions.

oplocs means that "Opportunistic Locking" is supported on a given share. This feature allows clients to do aggressive local caching, which in some (perhaps most) scenarios can yield significant performance gains, and in others have the exact opposite effect.

If a client opens a file for exclusive access, oplocks are very helpful. If a file is opened non-exclusively, oplocks may cause a significant delay if the same file is later opened (again, non-excusively) by another client, as the first client must then be made to flush its cache.

Oplocks should never be allowed on shared database files, so make sure to use the veto oplock files option if you allow oplocks on shares containing such files.