Slow samba/nfs read in OpenWrt stable/dev

That would equate to around 120MB/s read and 59MB/s write speed, so the connection is not the issue.

The next step would be opening top and then transferring a big file, watching the overall CPU load and which processes are the highest.

Edit: With yesterday's snapshot build (r10586) and currently latest cifsd (kmod-fs-cifsd 4.19.57+2019-07-17-0c3049e8-1) I get the same ~42MB/s read and ~35MB/s write I got before, maxing out the CPU in the process. This is on a WD My Book Live which, hardware-wise, shouldn't be inferior to your Zyxel NAS.

Hi, I posted the top ressults in comments 9 a 10 I think, I am not at home, so I can't add the new one. I don't know where is the problem :frowning:

Wait, you are testing this remotely, over the internet? To check the performance, you should do it in the wired LAN itself, not even over wifi. Everything else will introduce its own overheads.

No, every tests are over cabel and in LAN, but today we have birthday party for Our childern, so we aren't at home

It seems to be CPU bound

5693 5190 admin S 28336 11% 80% /usr/sbin/smbd -F

Yes, it can be, but why - original firmare has read/write speed 50/35 MB/s (over nfs)

OpenWRT is generally slower than the original firmwares: recent and heavier kernels with more functionality, no hw acceleration, etc.

Ok, but so why is write speed ok - near the original fw write speed :frowning: ?

That I would not know: I use the router for routing only.

Oh, I remembered that I did run samba on a router at one point years ago and the following settings helped me last time:
socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536

BTW, can you compare samba options between the stock and OpenWRT firmware? There could be a clue in there.

UPDATE: https://www.samba.org/samba/docs/old/Samba3-HOWTO/speed.html
UPDATE2: https://calomel.org/samba_optimize.html

1 Like

Ok, thank You a lot, I'll try it

My speed is 14MB/s (2GB file) using cifsd as server

root@NSA310:~# hdparm -Tt /dev/sda1

/dev/sda1:
 Timing cached reads:   428 MB in  2.01 seconds = 213.32 MB/sec
 Timing buffered disk reads: 370 MB in  3.01 seconds = 122.89 MB/sec
root@NSA310:~# opkg list | grep cifsd
cifsd-tools - 2019-07-05-539fa21a-2 - Userspace tools (cifsd, cifsadmin) for the CIFS/SMB kernel fileserver. The config file location is /etc/cifs/smb.conf
kmod-fs-cifsd - 4.14.132+2019-07-17-0c3049e8-1 - Kernel module for a CIFS/SMBv2,3 fileserver.

In logs I have:

Mon Jul 29 11:20:51 2019 kern.err kernel: [51215.420589] kcifsd: smb2_ioctl:6584: br-lan speed is unknown, defaulting to 100
Mon Jul 29 11:20:51 2019 kern.err kernel: [51215.427970] kcifsd: smb2_ioctl:6584: wg0 speed is unknown, defaulting to 100

Could this cause any slow downs ?

Maybe, will forward this to upstream.

Pretty sure that's only cosmetical

thank You kofec, I have the same I think:

root@OpenWrt:~# hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 442 MB in 2.00 seconds = 220.82 MB/sec
Timing buffered disk reads: 360 MB in 3.02 seconds = 119.37 MB/sec
root@OpenWrt:~#

and something changed - the read speed is back to 13-14 MB/s, slower than original, but equal to Your sped

(up to date openwrt dev)

There is a new bug entry that might be related to this: https://bugzilla.samba.org/show_bug.cgi?id=14095

So going by this, Sendfile is broken for all newer 4.1+ samba versions, yet Sendfile is only used if aio is disabled, which is enabled by default. So platforms with working aio "should" be unaffected by the sendfile bug.

So if you suffer from slow speeds, maybe give forced synchronous transfers a try, while avoiding the sendfile bug via those settings:

aio read size = 0
aio write size = 0
use sendfile = no

This certainly helps with a little more CPU load.

Hi, after long time - I found the solution, unfortunately the solution is debian :-/ - r/w speed is 25/25 MB/s with samba, with scp is it 8 MB/s r/w in debian, 2.3 MB/s in openwrt

I know no, where is the problem :-/

but debian in more usable for me

sorry a thank You for Your patience

rutu

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.