Nemo and slow transfer rate issue

All that remains is to wait for a gvfs fix. :wink:

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! :slight_smile:

Maybe in the next 4 years you will have it.
I think they don’t care, they think half the maximum throughput is enough :slight_smile:
After all, i think most users don’t care either, and advanced users do not use gvfs a lot and prefer to do their mount manually with fstab or with a systemd unit.
I personally no longer use smb protocol because i do not have any windows machine at home anymore

@yannssolo, I understand…from what you say there is no hope of fixes! :wink: Anyway, I will try the fstab method.

The thing I don’t like about fstab is writing plain text passwords in a text file, I don’t have any status secrets in my server and anyway is not exposed to the external network, but still it’s not too nice for my taste.

Anyway, if I remember correctly there is some way not to put the password in clear, I made it some time ago, I will have to search on the net.

https://www.freedesktop.org/software/systemd/man/systemd.mount.html
https://wiki.archlinux.org/index.php/fstab#Automatic_unmount

You can do it in a systemd unit too
There are a lot of options, as auto-mount, timeout and so on.

1 Like

Sorry, off-topic: linux-latest and linux-lts have been removed from the repo…

@yannssolo Okay, I will document. Thanks for your all kind replies.

And also, there are guides here done by @linux-aarhus to become a master with systemd unit

1 Like

No apologies needed. I think we’re pretty much done here. :slight_smile:
But I found both meta-packages here: Discover Packages On Manjaro Linux

https://discover.manjaro.org/packages/linux-lts

https://discover.manjaro.org/packages/linux-latest

Are they planning to remove them? :hushed: They serve a wonderful role, in my opinion. Have the latest copy of the designated LTS and STABLE kernels. Updates have been a breeze for me.

1 Like

I’m definitely going to check that out myself. I might not end up using it, but I love to learn alternatives for every use-case. :sunglasses:

They are gone from the repository already. Discover does not seem to be up-to-date.

Imho it’s a good decision to get rid of them. msm notifies you anyways when there is a new kernel version available…

While it might be convenient for some users it might cause issues for others when the kernel is automagically upgraded to another version.

According with @yannssolo says, this is the definitive proof that gvfs or gvfs-smb are problematic!

Added in the fstab one of four remote samba shares in ubuntu server, mount it and then:

time rsync -v --progress myVeryLargeFile.ext /run/media/giagio/public/
myVeryLargeFile.ext
2,147,483,648 100% 909.40MB/s 0:00:02 (xfr#1, to-chk=0/1)

sent 2,148,008,028 bytes received 35 bytes 104,780,881.12 bytes/sec
total size is 2,147,483,648 speedup is 1.00

real 0m20.775s
user 0m0.957s
sys 0m2.224s

boom!!! :wink:

That’s awesome to see! So now like @yannssolo mentioned, you have some options. Using systemd mount units, you can configure “auto” mounts based on attempting to access the share/folder, idle timeouts, among other options.

The “old-school way” to do this was either directly in the fstab (not always preferable, since the network share might not always be available), or with the autofs tools.

However, @yannssolo’s proposition looks more appealing as systemd is newer, yet matured and stable. I have never tried it before, but I’m interested to give it a shot, even just for the sake of learning. I might even end up using it. :grin:

@winnie fstab allows you automout too, or waiting the remote server to be available by delaying the mount a little bit…see the fstab section there systemd.mount

Then, the smart way is to store username and password in an external file and set permission 600 (rw-------). Instead of having username and password in your fstab mount, you have something like this:

//server/share/ /mnt/localmountpoint cifs credentials=/your_path/.smbpass …

Where the file .smbpass contains :

username=value
password=value

The advantage to do it in a systemd unit is that you can view the logs easily and they are more explicit than if using fstab.
In my opinion, not to have to edit your fstab is better, because it’s safer.

2 Likes

Huh, you can’t have 900 MB/s throughput in a gigabit lan, it should be 10 gigabit.

In gigabit you have a theoretically max throughput to 120 MB/s, a little more if using jumbo frames and a little less without them.

Look at the “time” results for “real time”. The test took about 20 seconds, which translates to around 103 MB/s. (2048 MB file divided by 20 seconds is about 103 MB/s.)

That’s why I advised @wuwei to use “time” for the rsync tests. Sometimes rsync spits out crazy “speeds” near the tail-end of a transfer.

Ah yes, i did not pay attention to the time, you’re right.

After reading the github issue at the link that @yannssolo suggested (large file throughput via gvfs-smb is over 2x slower than smbclient or fstab mount.cifs) I have to make a necessary correction; the issue is not related to gvfs-smb, but gvfs, indeed seems that gvfs lost an important parameter, -o big_writes:

ps waux | grep fuse
giagio 687 0.0 0.0 379060 6268 ? Sl 04:24 0:00 /usr/lib/gvfsd-fuse /run/user/1000/gvfs -f

the option is not present.

And that’s why things are better on mint:

mint@mint:~$ ps waux | grep fuse
mint 2437 0.0 0.0 378336 6552 ? Sl 04:10 0:00 /usr/libexec/gvfsd-fuse /run/user/999/gvfs -f -o big_writes

the difference is the -o big_writes option that’s present in that case.
It would be interesting to know if it’s possible to pass the -o big_writes parameter to gvfsd-fuse in Manjaro.

NAME
       gvfsd-fuse - Fuse daemon for gvfs

OPTIONS

       -o OPTION
           Set a fuse-specific option. See the fuse documentation for a list of these.

UPDATE: big_writes is no more present in fuse consulting its man, so this is because that parameter is no more used.

@wuwei, at this point I believe you’ll get the best performance using systemd mount units, and protecting the username/password for the network share by doing what @yannssolo suggests, in making it read-write (or even read-only) for only your user account.

You can always play around with putting shortcuts to these shared network folders on your Nemo sidepane or Desktop or wherever. :slight_smile:

Thanks man, after hours of changing samba config options and testing around with different benchmarks to test network and disk speeds I finally have an answer.
Copying a file in a normal samba share in nautilus gave me speeds of around 25MB/s.
Mounting it with cifs I now get around 110MB/s which is pretty much at the maximum for my network.

I would have never found out…

/ the problem is, that it’s hard to find this thread or anything related to this bug, when you search for „samba share too slow“ or something. Because that search results in hundreds of results talking about samba socket settings and such.

2 Likes