hi everybody, i have a problem wit speed transfer, i use rockstor 3.8.16
windows 10 to rockstor 115Mo sec ----- no problem
windows 10 to linux(all distro) 115Mo sec ------ no problem
rockstor to linux(all distro) 45Mo to 65Mo sec—problem
Yes this is a know limitation on the client side when using gvfs (which in turn uses libsmbclient) where as if you test the same hardware having made the mount via for example 'mount -t cifs …" you would see the expected full line speed. Rather unfortunate that the linux desktop clients don’t have this one sorted yet. But it use to be much slower.
You should be able to test the difference by first mounting, as I suspect you already have, via libsmbclient/gvfs ie via most gui tools such as nautilus or whatever the kde file manager is called these days “smb://rockhp.lan/samba-test/” style. And then compare those results with a mount achieve via for example:
sudo mount -t cifs -o username=test,password=testpass //rock.lan/samba-test /mnt/
which bypasses libsmbclient.
My tests a while while back gave 102 to 104 MB/s for the straight mount t cifs but only 38-58 MB/s for the nautilus / smbget type arrangement.
One can also do a gvfs mount via the command line with something akin to:
gvfs-mount smb://SERVER-IP/Share
to rule out other elements.
It’s been a very long standing issue that is quite disappointing for us linux desktop users.
This has come up before and you might find the discussion of it in the following closed pull request of interest:
EDIT OK forgot to post the relevant link so here it is:
ie 103 MB/s vs 48 MB/s for the 2 different mount methods.
See particularly my comments on 26 Nov 2016 as it contains upstream references acknowledging the performance problem. I haven’t looked into this again since that post but I recently only saw line half speed on my fedora desktop after mounting via Nautilus.
So essentially this is a linux desktop client issue not a Rockstor samba server issue.
@buzzbuzz Sorry forgot to put in the referenced link which contained the upstream references/discussion so I have edited my last post. Also you might find GUI utilities that serve your purpose smb mount wise that don’t rely on libsmbclient as then you should get full speed. I’ll take another look myself in a bit and will report back here if anything comes up. Plus now we have this thread, hopefully others can chip in with how they do things linux desktop smb client mount wise.
Maybe it would be germane to mention it on the RockStor website that this limitation exists for linux gui clients and that selecting another NAS solution might be more usable until their current distro fixes the problem
would certainly save people the time of downloading, installing and configuring RockStor only to find that transfers are limited to 10MB/s over a gigabit LAN
will try the alternative mount solution and see if situation improves (a shame this limitation is in place) - RockStor looked like a promising solution
It’s worth noting, this is not an issue with Rockstor, but with the Linux gvfs client.
If you’re looking at any alternative *nix OSS NAS solutions (Such as OpenMediaVault, FreeNAS, etc), you’re going to end up with the same issues.
A quick google verified the issue also exists on FreeNAS which is built on FreeBSD Unix as opposed to CentOS Linux.
I love car analogies, with that in mind - do you blame your car manufacturer if your car fails to drive on a flooded road?
@phillxnet has provided an alternative (mounting manually with CIFS instead of using gvfs/libsmbclient) which resolves the issue with a negligable amount of effort, especially for somebody who is (assumedly) experienced enough to be running linux as a GUI client.
Bearing in mind that I am not affiliated with the Rockstor team, I do see where you’re coming from.
I don’t however, think the onus is on the Rockstor devs (who have more important things to do, like building this epic NAS for you and me) to provide this warning - in the same way that no other open source NAS I’ve looked at mentions this ageing issue.
I don’t think it’s realistic for a small development team to be spending too much time documenting issues that that are not on their end.