Why is CIFS-mounted share faster than SMB?

To start with, this question isn't really a problem I have but rather a "why is it like this". I'm trying to return to Linux after several years in the Windows world, but I have lost so much... So here's to learning anew. :)

I have a Windows 10 x64 machine acting as file server in my network. I access the shares from Ubuntu Mate 16.04. Main file browser is Caja.

Here's the good part: When I browse the network shares on my network and start to copy a file, max speed is around 600 Mbit. But when I mount the share permanently in Fstab with CIFS (according to https://help.ubuntu.com/community/MountWindowsSharesPermanently) I can utilize my full link speed (1 Gbit). I can utilize the full link speed when using smbclient via Terminal as well.

Can anyone explain to me why this is the case with Caja (and Nautilus from what I can tell) and perhaps give me some links where I can read more about it? Aren't CIFS and SMB basically the same thing?

Thanks!

Update: I'm using an Intel I217-V (rev 04) NIC.

Solution 1:

SMB is a server Message Block which was invented by IBM to write files across a LAN network. CIFS is a Common Internet File System. CIFS is particular implementation of SMB done by Microsoft.

1.) The CIFS implementation of SMB is rarely used these days. Most modern storage systems no longer use CIFS, they use SMB 2 or SMB 3. In the Windows world, SMB 2 has been the standard as of Windows Vista (2006) and SMB 3 is part of Windows 8 and Windows Server 2012.

2.) SMB 2 and SMB 3 are massive upgrades over the CIFS implementation.

Now something to keep in mind (TCP window size * 8bits / RTT in milliseconds) = Max TCP throughput in bps. While you might have a Gigabit network a single TCP flow won't likely be able to get that high.

Now to optimize SMB config:

[global]

SEE: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798532

strict allocate = Yes

SEE: https://lists.samba.org/archive/samba-technical/2014-July/101304.html

allocation roundup size = 4096

Allow reado of 65535 bytes in one packet

read raw = Yes

Server signing slows things down.

server signing = No

Support RAW write.

write raw = Yes

"strict locking = auto" OR "strict locking = no" is acceptible.

strict locking = No

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072

"min receivefile size" will be passed directly to the kernel, recvfile/splice SYSTEM CALL.

min receivefile size = 16384

Use more efficient sendfile()system call

use sendfile = Yes

Samba musty be built with Asynchronous file support I/O support

aio read size = 16384
aio write size = 16384

Also in my case i needed to change the order of the name lookups in nsswitch.conf. It turns out that this configuration contained a line like this.

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4 

Simply adding a "wins" to the hosts line fixed the problem.

hosts:          files wins mdns4_minimal [NOTFOUND=return] dns mdns4