I’m getting very slow performance with a linux NAS mounted with CIFS to my local desktop. Oddly, the problem is only in one direction - file transfers from the desktop client to the NAS. Also, sending files with smbclient gives decent speeds both directions (>90MB/sec), so it’s something specific to the CIFS mount:
**Desktop->NAS == 8MB/sec
NAS->Desktop == 105MB/sec
**I’m using password authentication, if it makes any difference.
LAN is 1000Gbps switched, full duplex.
An NFS mount works fine.
I’m not too clear on the different standards, but it looks like CIFS is a variant of SMBFS? The ‘smbfs’ mount option has been removed, so I can’t see if it would work any better. Also, smbmount looks like a useful utility, but it’s been pulled from the repos…
Does anyone have any ideas?
notes:
I’ve tried various mount params without any luck:
cache mode to none
rsize and wsize to various sizes (from 4096 up to the large default)
Is it safe to assume you’re transferring one big file, vs. many little
files? If not, could you?
Have you tested with something that natively implements SMB (i.e. an
interior, but alternative, operating system)? How do the results compare
there when mapping a drive and copying files in each way?
A LAN trace may be interesting. I would guess, since “downloading” is
fast, that both options are using the same version of SMB, but maybe not.
Have you compared with, or tried, openSUSE Leap 42.2? I also see
something about SUSE-SLE_12 in your data; are you pulling data from SUSE
Linux Enterprise (SLE) repositories too?
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
Have you tested with something that natively implements SMB (i.e. an
interior, but alternative, operating system)? How do the results compare
there when mapping a drive and copying files in each way?
Not yet. I have access to a local iMac and will give that a try.
A LAN trace may be interesting. I would guess, since “downloading” is
fast, that both options are using the same version of SMB, but maybe not.
I saw something potentially interesting with Wireshark; smbclient uses much larger packet sizes compared to mount -t cifs:
left: local smbclient->NAS file transfer
right: local mount -t cifs, file copied to NAS
same direction, quite a different dialog
Have you compared with, or tried, openSUSE Leap 42.2? I also see
something about SUSE-SLE_12 in your data; are you pulling data from SUSE
Linux Enterprise (SLE) repositories too?
If you look at the TCP window size, which Wireshark can probably graph for
you over the course of the transfers, do you see it filling up all of the
way at all? This is just odd to me, but it’s technically different code.
Yep, I’ve tried the suggestions on that page - setting vers=2.0, rsize/wsize values, etc.
I’ve also tried enforcing SMB2 protocol from the server end.
‘cat /proc/mounts | grep nas’ returns the mount details and the rsize/wsize looks reasonable:
rsize=65536,wsize=65536
From looking at Wireshark again; I don’t fully understand TCP window size, but it looks like the NAS is advertising a value of 48790 but ‘mount -t cifs’ on the desktop is still sending very small TCP segments of around 2896 bytes (and then only splits it up into two parts to reassemble).
But smbclient is sending up to 4 reassembled parts and each TCP segment is much larger (up to 42468 bytes).
