# Samba CIFS – Filetransfer extremly slow

## Palatonka

After switching kernel from 4.4 to 4.9 cifs filetransfers are extremly slow (more than the fifth!).

Unfortunately I can't imagine what this difference causes.

Using windows share mounted with cifs.

Thanks in advance for any help and kind regards.Last edited by Palatonka on Mon Feb 27, 2017 10:27 am; edited 3 times in total

----------

## Jaglover

 *Palatonka wrote:*   

> After switching kernel from 4.4 to 4.9 NFS filetransfers are extremly slow (more than the fifth!).
> 
> Unfortunately I can't imagine what this difference causes.
> 
> What has changed in kernel 4.9 regarding NFS that could cause this issue?
> ...

 

Confusing. What version of NFS? What has CIFS to do with it?

----------

## Palatonka

Here is the mount info:

//SRV-123/backup on /mnt/backupserver type cifs (rw,relatime,vers=1.0,cache=strict,username=backupusr,domain=mydomain,uid=0,noforceuid,gid=0,

noforcegid,addr=10.10.0.11,file_mode=0755,dir_mode=0755,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1,

user=backupusr)

[Moderator edit: broke very long whitespace-free comma-separated list to improve output layout. -Hu]

----------

## Ant P.

If this actually has anything to do with NFS, post the output of `rpcinfo` on the client/server. Otherwise fix the thread title.

----------

## axl

 *Palatonka wrote:*   

> Here is the mount info:
> 
> //SRV-123/backup on /mnt/backupserver type cifs (rw,relatime,vers=1.0,cache=strict,username=backupusr,domain=mydomain,uid=0,noforceuid,gid=0,
> 
> noforcegid,addr=10.10.0.11,file_mode=0755,dir_mode=0755,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1,
> ...

 

this mount info points to samba not nfs. maybe take a look over the logs  of those services. just a thought.

----------

## threadau

I've noticed my Samba access has got extremely slow recently as well - but no kernel change, still on 4.4.x

I'm not talking about 20% speed, though. I'm lucky to get 50 KB/s.

----------

## threadau

As an update...I myself updated to the latest stable kernel (4.9.6), no change.

Don't want to thread-jack, so can start a new one. But my other observations is that I can transfer small files fine (i.e. <100 kB), but larger ones (smallest tried was 30 MB) panic and stop after a couple of MB transferred.

----------

## ct85711

This is sounding like the 2 of you may want to go through all changes done on both systems from the time that it was working correctly sense (this does mean it can include a couple months or more of changes).  I am assuming you control/manage the server side too, if not just one less system to check (but doesn't mean it's removed from the equation, just makes it an unknown).

Note, this is a good practice to do when troubleshooting an issue (always starting from last known good time).  Checking logs is also a good habit to do, even when you don't have an issue.  (yes, there is a log of packages installed in the log directory, I'll let you find them among others that you should already be familiar with).

----------

## threadau

Thanks ct85711 (do people call you ct?),

I started putting 2 and 2 and 3 together last night, and it's a "kick yourself" solution. I was pretty confident I had no significant changes on my Gentoo server, but I couldn't get large file transfers working from 2x Windows 10 clients, 1x Windows 7 client, and 1x OSX client.

I ran testparm, and smb.conf was as I remembered - very simple. Finally, I noticed that my ssh sessions had been kind of laggy recently, so I did some pinging. It seemed normal at <0.3 ms, then...

20% packet loss in one direction (client to server). In the other direction (server to client), even stranger. I could always get 12-16 good pings, then 100% loss for any more after that. I can only guess that a dozen or so packets was enough to shift 50-100 kB files over samba, but anything larger hit the wall.

So, now one of my Gigabit switches is sitting in the corner, thinking about what a bad boy it's been. I've been digging through forums, bug-trackers and config files for days!!! With this out of the way...I'm getting 75 MB/s after protocol etc.

With respect to the OP though, i can finally report "no change" with kernel 4.9 on my system. (As a side note...who makes good quality, basic switches?)

----------

## kilburna

I have the exact problem after switching from kernel 4.4 to 4.9. 4.4 was working perfectly for months. Since switching to 4.9, I am getting timeouts and failures randomly. This is not hardware related as I have new equipment and the kernel change was the only thing done.

I read another article that cifs has changed a bit since since 4.4. I have not yet found a solution.

I have 4.9 cifs slower than 4.4. 

```

//192.168.5.1/Sales on /mnt/sales type cifs (rw,relatime,vers=1.0,cache=strict,username=XXXX,domain=XXXXX,uid=0,noforceuid,gid=0,noforcegid,

addr=192.168.5.1,file_mode=0755,dir_mode=0755,nounix,serverino,mapposix,rsize=61440,wsize=16580,echo_interval=60,actimeo=1)
```

[Moderator edit: added [code] tags to preserve output layout; broke long whitespace-free line to fix thread layout. -Hu]

----------

## ct85711

Just out of curiosity, see if the problem exists on say either a 4.8 or a 4.10 kernel.  I noticed a couple bug reports on Fedora indicating a possible issue with the power safe mode.  Now, I don't know how much I trust those bug reports as I didn't see anything else pop up indicating the same thing.  Either way, testing a different kernel should help us confirm or deny that the kernel is the cause.

----------

## axl

I would test if other protocols are faster than cifs. nfs scp ftp come to mind. those are very fast and easy to test. it's a good way to determine if the line is capable of higher speeds. 

second, i'm not entirely sure if the problem originates from server or client. kernel 4.4/4.8 i assume is the clients kernel. the one doing the mount. but perhaps the server changed too. any detail on the server part?

and third, I had to stick to 4.4 because of an acpi bug that made the system limp with one core. 4.8/9/10 now series is the second most bleeding edge type kernel they have. 

usually when linus releases a kernel from 4.4 series, he also releases a version of the 4.8/9/10 series. same bugfixes. some differences ofc. like today. 4.10.5. 4.4.56.

----------

