Yes, I too strongly suspect some problems in the samba related packages, based on the tests done lead me to believe this, but I just have no way to prove it. I only hope in some update that fix the problem (samba/cifs packets?)
To clarify, the first test that you suggested (sync, time rsync etc) was performed both in a manjaro system installed in an external SSD drive but connected in usb2 (in that PC the usb3 isnāt recognized as bootable, old 10 years pc, ASUS M5A78L-M / USB3, AMD FX 4100, 16Gb RAM DDR3, SSD for linux system), and in systems installed on SSD disks and connected in normal SATA mode. They always give the same poor result.
Understood, but just to rule out Samba per se, Iām curious what the same test will look like bypassing any network or SMB protocal, from your SATA SSD to an external USB 3.0 drive, rsyncing the file over to a temporary folder on the USB 3.0 drive.
Ok, Iāll see if I can take the test you tell me then Iāll tell you what I get.
UPDATE: my first error about USB3! 
At first time test I didnāt attached the external usb3 SSD drive on the USB3 backports, but on the USB3 front port that is attached to a pcie USB3 device not recognized at boot, only by system drivers! So now test is becoming betterā¦
If you use GVFS to do your transfers, you would not have more than half the maximum throughput with a gigabit connection.
This is due to and old bug, still not fixed large file throughput via gvfs-smb is over 2x slower than smbclient or fstab mount.cifs (#292) Ā· Issues Ā· GNOME / gvfs Ā· GitLab
Disable your gvfs mounts and add an entry to your fstab to mount your samba shares locally:
//server_ip /local_mount_point cifs username=your_username,password=your_password,gid=1000,uid=1000,iocharset=utf8,vers=3.1.1 0 0
(change the options accordingly, but note the vers=3.1.1 (so you can have min protocol = SMB3 on server side).
This way, you could have 80-100 MB/s with big files
2 Likes
Winnie, great man!!
What do you think about this???
rsync -av myVeryLargeFile.ext --progress giagio@192.168.1.18:/home/giagio/Downloads/
sending incremental file list
myVeryLargeFile.ext
2,147,483,648 100% 110.77MB/s 0:00:18 (xfr#1, to-chk=0/1)
sent 2,148,008,052 bytes received 35 bytes 99,907,352.88 bytes/sec
total size is 2,147,483,648 speedup is 1.00
Definitely noteworthy, but seeing their speeds at 24 to 28 MB/s (which is about 190 to 220 Mbps) is well below the halfway mark of 500 Mbps for a gigabit connection. As for GVFS, Iāll have to test it on my other system, since with KDE (kio-fuse, instead of gvfs), I can hit near 900 Mbps for a single large transfer.
Your test, bypassing GVFS, would be very interesting to see their results.
So far, what I can gather (without tinkering with any smb/smbd .conf files):
They reach near gigabit speeds when bypassing storage devices and the SMB protocol
They get terrible speeds (24 to 28 MB/s) when bypassing their file manager, yet using GVFS and the SMB protocol
Letās see what the next tests yield.
Thank you, yannssolo, is that what I suspectedā¦Iām my very first opinion, with all the tests done I knew that the problem was caused by package gvfs-smb, even if I didnāt knew the related bug.
Iām confused by that test. You sent the file to the same computer (IP)? Back to āitselfā?
Thereās no ātimeā to see the real user time, but either way, rsync provided a rough estimate of 111 MB/s.
Can you try the following two tests?
- @yannssolo is alluding to GVFS as a possible culprit, which might in fact be the case. Their instructions bypass GVFS by creating an entry directly in your /etc/fstab using the CIFS (SMB) protocol.
- The local transfer from SATA SSD to USB 3.0 external.
Think of GVFS and KIO-FUSE (KDE) as sort of abstraction layers to help āintegrateā GNOME, Xfce, and KDE with outside sources, such as SMB shares in your case.
my last rsync test is significant that gvfs-smb needs fixing
Thanks to all you, men! Manjaro community really great!
Ohhh geeesh! Thatās terrible.
I was confused since I read our posts (the three of us) in the wrong order! 
Iām going to try something out on my Linux Mint laptop, which uses GVFS.
My āamazing speedsā were on my KDE Manjaro system.
But, if you bypass the file manager, with an entry in the fstab, you no longer use gvfs, no ?
I mean, you can have gvfs mount in Thunar fir instance (by enabling volume management) and also have a mount in your fstab.
So, if you use the mount done by your fstab, you do not use gvfs.
I made dozens of tests (though it was last year), with different distros, i tried maybe 10 different file managers, tried to tweak the server, but once you use gvfs stuff, sometimes i achieve 30 MB/s, sometimes 50 or 55 if you are lucky, but never more.
1 Like
I can say to you that Mint has good results, infact in my old setup with Mint 19.3, transfer rate using Nemo and gvfs was about 70/75 Mb/s (value reported in nemoās copy window without the most accurate tests we did together with winnie). Could be even better, but anyway acceptable, rather than poor values in Manjaro / Arch.
interesting 
You nailed it on the headā¦ Iām beside myself at how nuts this is. A four-year-old bug? Thatās insane.
I just tested this out on my Linux Mint (Cinnamon) system, and Iām getting the same terrible speeds as @wuwei ! I primarily use my Manjaro KDE computer, and itās where I do most of my transfers to and from my NAS server (SMB shares).
Thank you for diving into this, @yannssolo ! 
@yannssolo, tomorrow I will do a test following your advice then I will report about the results. Thanks again!
@wuwei , at the end of the day, you can at least use a static fstab entry, or use āautoā mount. Neither are as user-friendly as simply opening up a network share (like a folder), and having the magic happen in the background on-the-fly without having to touch any config or text files. I understand.
For some reason kio-fuse under KDE yields near gigabit speeds for me, but the same test using GVFS cuts that in half (and lower!) 
Just wowā¦
@winnie, I know tooā¦The magical tools in the file manager make life easier, butā¦what can we do if there are buggy packages? 
developers should gather information from posts like this to make things better, but that often doesnāt happen.
About kde plasma I can say that it is beautiful, but in my PC it turns out to be too heavy, otherwise I would have made the switch to that desktop. Main main linux PC is dated 2014, an ex-hackintosh converted to ālinuxtoshā: MB GA-Z97-D3H, intel i3-4160, 16 Gb RAM DDR3, various SSD disks, yet a good machine, but Plasma results little heavy for me.
Well the great irony is, KDE must have undergone same rapd bug-squashing in recent times, since kio-fuse used to be slower than GVFS. 
I assumed that once kio-fuse ācaught upā to GVFS, that all was good in the world, and there would be rejoicing across the lands. Turns out, they switched sides and now GVFS has to ācatch upā. (EDIT: This might not be true. Need to check something else to be sure.)
Oh boy.
On the bright side, now you have a few more tools in your pocket to run your own troubleshooting and diagnostics. I looked over some related bug reports and they used the same concept (large random file, rsync, and ātimeā command) to diagnose the performance. Maybe thatās what they call āconvergent mindsā since I swear I thought that was my original idea. Guess someone else thought of it well before I did. 
All that remains is to wait for a gvfs fix.
What I canāt understand is why the tests conducted with Manjaro and gvfs-smb 1.46.1-1 gave decent transfer rates (70-75 Mb/s), while with the update to version 1.48.0-2 everything got worse (40 Mb/s). They are inexplicable things, like the mysteries of the universe!