NFS Slow speed in one direction ?

[pm-alonso]

Hi !

thank you so much for this:
https://github.com/zilexa/Homeserver/tree/master/network%20share%20(NFSv4.2)

I have followed the instructions and got running two raspberry pi arm64 with this setup.
I have a question since in one direction speed seems great and in the other directions speed is half the expected.

pi@desk:/ $ rsync -vrth --progress /Storage_5TB_nfs/temp/ /Storage_4TB/temp/
sending incremental file list
./
test1.mp4
732.95M 100% 44.89MB/s 0:00:15 (xfr#1, to-chk=2/4)
test2.img
52.43M 100% 24.17MB/s 0:00:02 (xfr#2, to-chk=0/4)

sent 785.57M bytes received 57 bytes 42.46M bytes/sec
total size is 795.87M speedup is 1.01

pi@desk:/ $ rsync --progress -vrth /Storage_4TB/temp/ /Storage_5TB_nfs/temp/
sending incremental file list
test5.mp4
732.95M 100% 91.33MB/s 0:00:07 (xfr#1, to-chk=0/4)

sent 733.13M bytes received 35 bytes 86.25M bytes/sec
total size is 795.87M speedup is 1.09

running the copy from the client (desk).
I get full network speed 1Gbit to transfer to nfs-server.
retrieving data from nfs-server to client (desk) the speed is the half....

found no reason for this... both hard drives have same specs and are able to write 120MB/s each easily with dd tool.

if someone can suggest something to fix this. I will appreciate...

Thanks.
Regards,

Pablo

[ZileXa]

I am no expert in how to perform speedtests, what I know:

• rsync does lot's of checksums, both during read and during write (most tools don't do that). For a clean test, perhaps this should be disabled.
• Raspberry Pi shares the LAN interface with USB interface.
• Are these 2.5" HDDs? If so, they are SMR disks (all 4TB and 5TB 2.5" disks are SMR disks, no exceptions) and the speed decrease is normal (it could even drop further). SMR disks perform lots of trickery to get an acceptable speed. The trickery is also performed when you think the activity has finished, since it might need to move entire blocks due to the previous copy action, which it is simply doing without you knowing it. For a clean test, use other types of HDD or use 2 identical and formatted USB sticks (format them after each individual test).

BTW I am no NFS expert at all, I would recommend posting your question in a place where more experts might notice it, if you believe NFS configuration is the issue here.

I have 4 of these 4/5TB disks that I do not use anymore because their speed, their noise (weird ticks) etc made them unreliable, even brand new ones started to make noises that clearly indicated defects, after just 5 weeks and barely used. Even though I was a big fan of 2.5" 4/5TB drives, I highly recommend to replace them if your data is precious.
1 of the 4 disks showed a very bad SMART report after 3 months, I had to instantly replace it. I had not even 1TB of data on it.

[pm-alonso]

Hi zilexa,

Thank you for your kind reply.
Your observations are very good indeed, but let me reply...

*rsync is the same tool used in one direction and the other. (equal conditions)
*raspberry pi 4b does a really great job with its 1gbps adapter. (nothing compared to previous models).
*HDs are SMR as you point out... and i am aware of the underlying issues and risks involved you describe. but...

I have today with more patience taken the time to carry out further tests.

I have setup nfs-server in the other Pi now. (following again your instructions)
I can reproduce now the same issue (one direction being half the speed) but in the reverse situation.

so to put it clean, what happens is this:

rsync run in raspi1 ==>
*transfer from raspi1 (with mounted nfs share) to raspi2 (nfs-server) gets maximun 1Gbit speed.
*transfer from raspi2 (nfs-server) to raspi1 (with mounted nfs share) gets half the speed.

rsync run in raspi2 ==>
*transfer from raspi1 (nfs-server) to raspi2 (with mounted nfs share) gets half the speed.
*transfer from raspi2 (with mounted nfs share) to raspi1 (nfs-server) gets maximun 1Gbit speed.

So this results i believe, show that something from NFS implementation differs from client to server rol or something happens that hinders performance for the client side only. (the client reads slower that the speed which it can deliver to write)

(somehow the client seems to read from server slower that the speed which it can deliver to write)

thanks!
Regards,

Pablo

[ZileXa]

I really do not know much about NFS, I just figured out how to install it and force the latest (2016!) version that has server-side copy support.

I actually stopped using NFS completely. Since I use FileRun, it had benefits to use a webDAV client to keep my laptop and other users PC's in sync. Benefits such as file indexing and thumbnail generation, so that you can search through the files and immediately benefit from fast thumbnail scrolling on your phone (via my FileRun site or CX File Explorer) or other devices..
I was afraid webDAV would not be suited to keep 3 accounts with 600GB of data in sync between my server and a laptop, plus 3 external (parents) accounts between my server and their systems (additional 180GB). So far it works fine on Ubuntu Budgie with NextCloud Desktop Client (the only Linux WebDAV client I could find with 2-way sync support, alternatives only let you access your files, adding a virtual folder, like Dropbox).

Apart from those benefits, there was something funky going on with btrfs & NFS combination and the NFS mount point. Once, I removed a mountpoint on my laptop and discovered 500GB on my server was deleted. My most precious data. Took me weeks to get it back.

To backup files to other locations, I use BTRFS send/receive which is much, much faster than rsync since it uses the metadata checksums of the filesystem, instead of generating checksums itself.