Is your Samba slow?

Samba file sharing is great, but performance under Samba’s default configuration is fairly poor.

Here are a few options that I add to my smb.conf to get the speed that I need:

# FORCE THE DISK SYSTEM TO ALLOCATE REAL STORAGE BLOCKS WHEN
# A FILE IS CREATED OR EXTENDED TO BE A GIVEN SIZE.
# THIS IS ONLY A GOOD OPTION FOR FILE SYSTEMS THAT SUPPORT
# UNWRITTEN EXTENTS LIKE XFS, EXT4, BTRFS, OCS2.
# IF YOU USE A FILE SYSTEM THAT DOES NOT SUPPORT UNWRITTEN
# EXTENTS, SET "strict allocate = no".
# NOTE: MAY WASTE DRIVE SPACE EVEN ON SUPPORTED FILE SYSTEMS
# SEE: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798532

   strict allocate = Yes

# THIS IS TO COUNTERACT SPACE WASTAGE THAT CAN BE 
# CAUSED BY THE PREVIOUS OPTION 
# SEE: https://lists.samba.org/archive/samba-technical/2014-July/101304.html

   allocation roundup size = 4096

# ALLOW READS OF 65535 BYTES IN ONE PACKET.
# THIS TYPICALLY PROVIDES A MAJOR PERFORMANCE BENEFIT.

   read raw = Yes

# SUPPORT RAW WRITE SMBs WHEN TRANSFERRING DATA FROM CLIENTS.

   write raw = Yes

# WHEN "strict locking = no", THE SERVER PERFORMS FILE LOCK
# CHECKS ONLY WHEN THE CLIENT EXPLICITLY ASKS FOR THEM.
# WELL-BEHAVED CLIENTS ALWAYS ASK FOR LOCK CHECKS WHEN IT IS
# IMPORTANT, SO IN THE VAST MAJORITY OF CASES,
# "strict locking = auto" OR "strict locking = no" IS ACCEPTABLE.

   strict locking = No

# TCP_NODELAY:
#    SEND AS MANY PACKETS AS NECESSARY TO KEEP DELAY LOW
# IPTOS_LOWDELAY:
#    [Linux IPv4 Tweak] MINIMIZE DELAYS FOR INTERACTIVE TRAFFIC
# SO_RCVBUF:
#    ENLARGE SYSTEM SOCKET RECEIVE BUFFER
# SO_SNDBUF:
#    ENLARGE SYSTEM SOCKET SEND BUFFER

   socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072

# SMBWriteX CALLS GREATER THAN "min receivefile size" WILL BE
# PASSED DIRECTLY TO KERNEL recvfile/splice SYSTEM CALL.
# TO ENABLE POSIX LARGE WRITE SUPPORT (SMB/CIFS WRITES UP TO 16MB),
# THIS OPTION MUST BE NONZERO.
# THIS OPTION WILL HAVE NO EFFECT IF SET ON A SMB SIGNED CONNECTION.
# MAX VALUE = 128k

   min receivefile size = 16384

# USE THE MORE EFFICIENT sendfile() SYSTEM CALL FOR EXCLUSIVELY
# OPLOCKED FILES.
# NOTE: ONLY FOR CLIENTS HIGHER THAN WINDOWS 98/Me

   use sendfile = Yes

# READ FROM FILE ASYNCHRONOUSLY WHEN SIZE OF REQUEST IS BIGGER
# THAN THIS VALUE.
# NOTE: SAMBA MUST BE BUILT WITH ASYNCHRONOUS I/O SUPPORT

   aio read size = 16384

# WRITE TO FILE ASYNCHRONOUSLY WHEN SIZE OF REQUEST IS BIGGER
# THAN THIS VALUE
# NOTE: SAMBA MUST BE BUILT WITH ASYNCHRONOUS I/O SUPPORT

   aio write size = 16384

A few other references:

5 Responses

  • Thanks for sharing.

    [Reply]
  • Thanks! Can you give us some examples of speeds that you achieved before and after, and some details about the hardware you used to run your tests?

    [Reply]
    • Dave, My particular setup is a Core i3 and a 7200 RPM SATA drive. I went from 25 MB/sec pre-config to 115 MB/sec post-config (which happens to be the same speed I get when directly accessing the drive). Unless you have an SSD or a RAID pool with lots of IOPS, the drive is going to be the bottleneck.

  • Thanks for your reply. I made the same changes (excluding the allocate tweaks) on my FreeBSD 10.3-RELEASE Samba 4.3 (ZFS) server and got no change at all. I get up/down speeds of ~24MB/s, even though I am able to SCP data up/down at around 80MB/s, and my ZFS array is capable of even faster speeds. Any other tips?

    [Reply]
    • Not sure if all of the "socket options" are applicable to FreeBSD. Also, "strict allocate = Yes" makes a pretty big difference.

      I did this under Linux. As for what low-level twiddling will get it up-to-par on FreeBSD (if that is even possible), I'd love to find out.


Leave a Reply


<a href="" title="">, <abbr title="">, <acronym title="">, <b>, <blockquote cite="">, <cite>, <code>, <del datetime="">, <em>, <i>, <q cite="">, <s>, <strike>, <strong>