Network share: Performance differences between NFS & SMB
Both SMB and NFS are network protocols of the application layer, used mainly for accessing files over the network. Since SMB is supported by Windows, many company and home networks use it by default. I will show you a basic benchmark based on read and write operations with both protocols.
Environment
The NAS device will be the target for read and write operations. It has a hard disk with a transfer rate of around 150 MB/s. All devices are connected over LAN. The NAS device is linked to FritzBox with 1000 Mbit/s. The bit rate between PC and FritzBox is set to 100 Mbit/s.
Hardware | Software |
AVM FRITZ!Box 7390 Wlan Router | Kubuntu 15.04 64Bit |
Synology DiskStation DS213J | DSM 5.2-5565 Update 2 |
WD Red NAS-HDD 1TB (150MB/s R/W) | Linux bash utils (cp, time, rm) |
Configuration
I have decided to use NFSv4 and SMBv2 with large MTU. An important difference between both protocols is the way they authenticate. NFS uses the host-based authentication system. This means that every user on an authenticated machine can access a specific share. However SMB provides a user-based authentication. Since NFSv4 it’s possible to use a Kerberos server, which extends the authentication system.
Enabling NFS and SMB in a Synology NAS (DSM) is done with a few clicks. As you can see below I have restricted read and write access to the network segment 10.10.0.0/24, which allows the access to a total amount of 254 hosts. You might split your network segment into two regions. The upper hosts might get read access whereas the lower hosts might get additionally write access. Just play around and find the configuration which meets your requirements.
Network share access with Linux
sudo apt-get install nfs-common cifs-utils
sudo mount -t cifs //IP-OF-YOUR-NAS/NAME-OF-SHARE /mnt/smb/ -o user=YourUserName
sudo mount IP-OF-YOUR-NAS:/NAME-OF-SHARE/ /mnt/nfs
Network share access with Windows
The SMB share can be mounted without any additional Software. The line below mounts the SMB share to drive X:\
net use X: \\IP-OF-YOUR-NAS\NAME-OF-SHARE /USER:YourUserName
If you own a Windows 7 Ultimate or Enterprise license, you can turn on Services-for-NFS inside Windows-Features. Others need 3rd-party software to access NFS shares. To be honest, accessing NFS is horrible if you don’t own the correct windows license. It’s not as easy as in Linux or Mac OS!
A solution, which is offered by the University of Michigan is only usable in TESTMODE. The provided driver is not digitally signed!
NFS vs SMB – Benchmark
Every test was repeated three times. The results were rounded up or down.
Files | NFS (write) | SMB (write) | NFS avg. | SMB avg. | ||||
10 KiB (6998 files) | 38s | 37s | 37s | 95s | 106s | 102s | 37s | 101s |
1 MiB (240 files) | 24s | 23s | 23s | 26s | 29s | 27s | 23s | 27s |
500 MiB (1 file) | 46s | 45s | 45s | 45s | 45s | 45s | 45s | 45s |
3,5 GiB (1 file) | 323s | 323s | 324s | 325s | 324s | 323s | 323s | 324s |
Write example: (time cp -f ~/tmp/test/10KB/* /mnt/smb/test/10KB/) && (rm -f /mnt/smb/test/10KB/*)
After each read test the local cache must be cleared. Otherwise the measurement will be wrong.
Files | NFS (read) | SMB (read) | NFS avg. | SMB avg. | ||||
10 KiB (6998 files) | 25s | 26s | 26s | 60s | 57s | 57s | 26s | 58s |
1 MiB (240 files) | 24s | 24s | 25s | 28s | 29s | 27s | 24s | 28s |
500 MiB (1 file) | 45s | 45s | 45s | 48s | 50s | 48s | 45s | 48s |
3,5 GiB (1 file) | 323s | 323s | 345s | 345s | 349s | 346s | 330s | 347s |
Read example: (time cp -f /mnt/nfs/test/1MB/* ~/tmp/test/1MB/) && (rm ~/tmp/test/1MB/* && sudo sh -c 'echo 1 >/proc/sys/vm/drop_caches' && sudo sh -c 'echo 2 >/proc/sys/vm/drop_caches' && sudo sh -c 'echo 3 >/proc/sys/vm/drop_caches')
Conclusion
As you can see NFS offers a better performance and is unbeatable if the files are medium sized or small. If the files are large enough the timings of both methods get closer to each other. Linux and Mac OS owners should use NFS instead of SMB. Sadly most Windows users are forced to use SMB.
>>> “Sadly most Windows users are forced to use SMB.”
SMB is more efficient than NFS protocol-wise. SMB is a stateful protocol, NFS is a stateless protocol. Once a connection is established, SMB has less overhead than NFS. However, SMB is more or less a Microsoft protocol. To get the best performance, you need to use Windows servers and clients. For Windows users, SMB is native and performs better than NFS, no real sadness.
Dear Jacky, you may be right that you get the best performance with SMB in a pure Windows only environment. In my opinion this is not realistic. Mixed environments like having Windows clients and Linux file servers or vice versa is not uncommon. In that case NFS shows a better performance.
I’m not sure this is a valid argument. I believe NFS has been stateful for 20 years now (since v4 came out).
Please … NFS can be stateful too! check NFS manual, you can switch to TCP.
I’ve always found SMB to be slow on every Windows Server I used; 20% network utilisation was the norm and could never figure out why. When using Synology servers, they always appear to consistently transfer files at 100% network speed. The only time it didn’t is if it was working with lots of tiny files. Maybe the biggest NFS gains is when transferring small files?
Synology! Benchmark! NFS and SMB!
That’s just the information I’ve been looking for! Thank you!
Synology is using Linux operation system.
Synology uses BSD
No.
https://developer.synology.com/developer-guide/create_package/compile_kernel_module.html
On ubuntu 14.04 I had the opposite experience, samba performed roughly 10% faster than nfs when reading a single (large) file. The network is 1GB/s, wired locally.
I use the default configs for both, any idea why I don’t get 200% speedup by using nfs like your numbers say?
Did you see that the performance for large files is nearly the same with NFS and SAMBA?
There is no big advantage. NFS is only better for small or medium sized files.
Ferhat
I did like the fact you showed the different file sizes in use.
The system that I will be building here soon uses many small files in a Read Only environment. So from the looks of it, the NFS is the better choice.
In my opinion it’s the better choice but you will find always other opinions about this.
At our work, we regularly run tons of the tests involving SMB and NFS shares and SSD disks. We use these results to design very fast NAS applications for data recording (1GbE, 10GbE and 40GbE). In each of these tests for sequencial disks access (writes or reads or both) SMB each time outperforms NFS by 10%-20% depending on the test case. We use it with single, multiple streams, and IP aliasing to maximize storage throughput.
Would be useful to know how this stacks up now with SMB3.
Would you mind if I took a screen shot of the benchmark itself for some project documentation I have to write for school? Of course, your name will be attached to the source’s section properly, but it would help a lot for the reasoning part. Not that we had a real choice in our fake project, though .. ? best wishes from .de,
a going-to-be admina in training ?
For sure, no problem. ?
Thank you very much!
Kein Problem. Viel Erfolg!
Hi Ferhat, nice article ?
If you are still in this game, and have the time, maybe an update with SMBv3 and NFS 3/4 would be a great follow-up to see if the VERY thorough testing is still valid ?
NIce work, especially testing the different file sizes, very much appreciated!
Hi Joseph, maybe in the future. Right now I am very busy with other projects. Thanks!
Thanks for the article.
A few days ago I installed Windows Server 2019 Standart on my NAS. And 2 days I tested the speed on apple tv 4k (1Gb network).
And as I can see its no big difference between NFS and smb share. In my case, smb has a more stable speed when test on big files.
Good article, and without any question, NFS, specifically NFS 4.x is super fast and better than any MS trash protocol.
SMB is not a shared network file system but ratter protocol definition. NFS is actually a network based shared file system.
stateful vs. stateless is totally wrong assumption …
There is reason why MS file systems are slow .. everything is tracked within protocol …