Question SMB 20x slower than NFS

Currently reading
Question SMB 20x slower than NFS

11
1
NAS
DS220j
Operating system
  1. Linux
Hey Folks,

Been directed here (as "some true experts on the topic are on synoforum.com") from Synology Community.


Long story short: I bought myself a first NAS - DS220j - that I plan to use at home.
As I am Linux user I was first looking at NFS mounts but because:

- setting up kerberos is apparently pain
- cannot mount encrypted folders

I am trying SMB. Due to my surprise SMB mount is 20x slower than SMB.
I was expecting it to be slower but not by this much!

Bellow details results of my tests show that on SMB I get ~5 MB/s. This cannot be
optimal as I've seen reports showing it should be much faster:
- Network share: Performance differences between NFS & SMB
- Synology Community
- NAS Performance: NFS vs. SMB vs. SSHFS


Method I used for measurement is similar to the one from the link #1. Plan to follow with method from #3 too.


Question: what can I be doing wrong and how can I get more decent speeds on SMB?


Basically mounts:
Bash:
# Mount of NFS
mount -t nfs doctor-chaos.local:/volume1/nfs-test /mnt/nfs

# Mount of SMB
sudo mount -t cifs -o credentials=/etc/smb-credentials,uid=1000,gid=1000 //doctor-chaos/encrypted-smb-test /mnt/smb/ --verbose

# Mount of SSHFS
sshfs -o Ciphers=aes128-ctr -o Compression=no -o ServerAliveCountMax=2 -o ServerAliveInterval=15 [email protected]:/encrypted-smb-test/ /mnt/sshfs

Preparation of data:
Bash:
HOST_DATA="/tmp/test-data"

rm -rf ${HOST_DATA}

mkdir -p ${HOST_DATA}/1MB
for n in {1..1000}; do
    dd if=/dev/urandom of=${HOST_DATA}/1MB/file$( printf %03d "$n" ).bin bs=1M count=1
done

mkdir -p ${HOST_DATA}/100MB
for n in {1..10}; do
    dd if=/dev/urandom of=${HOST_DATA}/100MB/file$( printf %03d "$n" ).bin bs=1M count=100
done

mkdir -p ${HOST_DATA}/500MB
for n in {1..2}; do
    dd if=/dev/urandom of=${HOST_DATA}/500MB/file$( printf %03d "$n" ).bin bs=1M count=500
done

mkdir -p ${HOST_DATA}/1GB
dd if=/dev/urandom of=${HOST_DATA}/1GB/file$( printf %03d "$n" ).bin bs=1M count=1000


NFS test:
Bash:
HOST_DATA="/tmp/test-data"

rm -rf /mnt/nfs/test
mkdir -p /mnt/nfs/test/1MB
mkdir -p /mnt/nfs/test/100MB
mkdir -p /mnt/nfs/test/500MB
mkdir -p /mnt/nfs/test/1GB

for n in {1..3}; do
    (time cp -f ${HOST_DATA}/1MB/* /mnt/nfs/test/1MB/) && (rm -f /mnt/nfs/test/1MB/*)
done

for n in {1..3}; do
    (time cp -f ${HOST_DATA}/100MB/* /mnt/nfs/test/100MB/) && (rm -f /mnt/nfs/test/100MB/*)
done

for n in {1..3}; do
    (time cp -f ${HOST_DATA}/500MB/* /mnt/nfs/test/500MB/) && (rm -f /mnt/nfs/test/500MB/*)
done

for n in {1..3}; do
    (time cp -f ${HOST_DATA}/1GB/* /mnt/nfs/test/1GB/) && (rm -f /mnt/nfs/test/1GB/*)
done


SMB test:
Bash:
HOST_DATA="/tmp/test-data"

rm -rf /mnt/smb/test
mkdir -p /mnt/smb/test/1MB
mkdir -p /mnt/smb/test/100MB
mkdir -p /mnt/smb/test/500MB
mkdir -p /mnt/smb/test/1GB

for n in {1..3}; do
    (time cp -f ${HOST_DATA}/1MB/* /mnt/smb/test/1MB/) && (rm -f /mnt/smb/test/1MB/*)
done

for n in {1..3}; do
    (time cp -f ${HOST_DATA}/100MB/* /mnt/smb/test/100MB/) && (rm -f /mnt/smb/test/100MB/*)
done

for n in {1..3}; do
    (time cp -f ${HOST_DATA}/500MB/* /mnt/smb/test/500MB/) && (rm -f /mnt/smb/test/500MB/*)
done

for n in {1..3}; do
    (time cp -f ${HOST_DATA}/1GB/* /mnt/smb/test/1GB/) && (rm -f /mnt/smb/test/1GB/*)
done


Note: rsync and sshfs tests are done in similar fashion - can post details if some one is interested but they are not part of the question so wanted to keep it simple.



Results:

qRN7cgq.png



SMB settings:
lP3dwMO.png
 
I may have figured it out and indeed I may have been doing something stupid...
I did have the samba share mounted twice: once in Budgie file browser and one from command line...

When I made sure I have it mount only once speeds went up to the sky!
Will check few more times just to be sure...


R19ZrQF.png
 
welcome here
so step by step analyze:
1. not clear from your setup. Do you have just one Volume in your NAS? Then same Volume for test scenarios?
2. try to set the SMB Transport encryption mode from Auto to Disable and make a test again.
 
I still try to confirm that this was the issue, but the only other thing I change was to enable `Apply default UNIX permissions` in SMB settings... Anyway, happy it works ; - )
 
So... because I am playing around and really wanted to understand what is the reason for the initial slow transfer - I cannot let it go things unless I really understand what's going on - I reinstalled the NAS and now I am stuck on the slow SMB transfer again... : - )
 
It must be something wrong with my mounting procedure.

If I speed test what gets mounted by Files (or whatever is Budgie filer browser called) as
Code:
/run/user/1000/gvfs/smb-share:server=doctor-chaos.local,share=smb-test

I get very decent times...
 
- cannot mount encrypted folders

The reason for that is:
Long story short: I bought myself a first NAS - DS220j - that I plan to use at home.

Should have stayed away from J series.. I bought a J serie once.. my gosh, I took it right back to the shop within an hour. Rubbish...
 
So in not J series I would be able to NFS-mount encrypted folders? Documentation seemed to state that this is limitation for encrypted folders, not the J series
 
I agree with shadow that J-types are to be used for simple storage only (and many people are happy to do so).

But as you state the synology documentation is clear that this is not a limitation to the J types, it is a general limitation on encrypted folders in combination with NFS.
 
different point of view from the NAS basics:
- any disk encryption needs power from CPU
- fast and sufficient RAM
- fast disk controller
- fast disk(s).

In this case is DS220j used for such operation:
- CPU: Realtek RTD1296 is responsible for entire system, encryption, disk controller (also for RAID if any)
- the CPU is based on ARM Cortex-A53 micro architecture = entry level SoCs, produced for not heavy home cinema end points (DTV set+top boxes, streaming players, ...) and budget smart phones in previous decade.
- 512MB RAM is handling all the operated data
- all Syno NASes uses stackable eCrryptfs for the file based encryption
- and eCrryptfs doesn’t useful for the NFS share

Conclusion - you can play with some speed-tune of samba (lot of recommendations you can find over internet), but you are still limited by your HW.
 
There are hardware limitations with no doubts here but this certainly not the reason for a slow transport I am observing.

The other day I managed to have a decent speeds and also if mounted through gvfs it is fine...
 
Ofc, you point is right.
My was just about boundaries definition.

NAS tuning is one of the legal happiness starter. But sometimes you will lose hours and nothing is happened.
Enjoy and cheers!
🍺
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

  • Question
yes,i can, i only try it on windows, i find the solution,i clone/make a new sharing folder with same file...
Replies
2
Views
1,325
  • Solved
Well, I sorted the problem out. I ensured that the Windows firewall rules were meant specifically for the...
Replies
16
Views
3,199
I can see that being a reasonable approach to updating, especially operating systems. As for AFP, I’ve...
Replies
6
Views
2,617
I can confirm that the latest smb update resolved the issue in my case. I can now save files directly on...
Replies
20
Views
3,361
Mounted SMB-volumes are ejected/unmounted maybe once or twice a day. Remounting is not possible (DS as...
Replies
0
Views
1,683
  • Solved
I registered on this forum only to thank you. I had exactly the same problem with exactly the same...
Replies
11
Views
8,054

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top