Browsing smb share is painfully slow when mounted via "gio" (compared with "mount")

[Pablo Copissa]

Reported upstream as issue 2062 (https://gitlab.gnome.org/GNOME/glib/issues/2062)

Ubuntu 18.04 LTS here, fully updated (as of late Jan 2020).
TEST #1:
To establish a baseline/expected behavior, we first mount an SMB share via mount.cifs and time an ls command:
$ sudo mount -t cifs -o username=pablo //myserver.example.com/share ~/mnt/share
$ cd ~/mnt/share/some/dir
$ time ls
... approx 320 files ...
real 0m1,080s
user 0m0,008s
sys 0m0,005s
$ sudo umount ~/mnt/share

TEST #2
Now we do the same via gio mount:
$ gio mount smb://myserver.example.com/share
cd /run/user/1000/gvfs/smb-share\:server\=myserver.example.com\,share\=share/some/dir
$ time ls
... same 320 files ...
real 0m28,999s
user 0m0,013s
sys 0m0,032s

Enumeration of files is about 29 times slower when mounted via gio mount than via mount -t cifs.

TEST #3
Now for the real weird: while using the gio-mounted folder, we now time ls IN COMBINATION WITH SOMETHING ELSE (can be strace ls, ls|wc etc...):
$ time ls | wc
   321 323 9804

real 0m0,546s
user 0m0,006s
sys 0m0,004s

Note that this is almost TWICE AS FAST than the "fast" mount of test #1 and about 53 times faster than "slow" test #2 !

The expectation is that Tests 1 and 2 should have similar timings, not differing by a factor of 30 or so. More disturbing, there is no good reason why tests 2 and 3 differ by an even bigger factor of 53: They use the same underlying infrastructure which test 3 proves is adequately fast. And yet, we get this slow down in test 2.

As a final note, these benchmarks are a distilled version of the original real-life motivating scenario where a Java-based program would simply take tens of minutes to display the same list of 320 files when mounted via gio mount and a second or so when mounted via mount -t cifs.
The same timing difference is of course visible in any file manager.

Hope this helps

PS: several old/ancient bug reports exist for a similar issue and I deliberately copied the title from one of them (#259771)

PS2: may or may not be relevant: The remote server is a VM running Windows 7 (yes, I know...) and the connection was made via VPN (Ubuntu stock SSTP).

PS3: Another data point (server is now a Synolgy NAS, not a Win7 VM)

$ gio mount smb://nas.example.com/share2

$ cd /run/user/1000/gvfs/smb-share\:server\=nas.example.com\,share\=share2/another/path

$ time ls

... 528 subdirs approximately ...

real 0m45,075s
user 0m0,013s
sys 0m0,058s

$ time ls | wc
    528 1631 10893

real 0m0,911s
user 0m0,003s
sys 0m0,005s

Factor is about 50.

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1862264/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Pablo Copissa (pcopissa)]

Looks like gio is part of glib, not gvfs, so changed the package accordingly.
Also made clear in the title that gio vs mount is part of the issue.

[Sebastien Bacher (seb128)]

Thank you for your bug report, that's likely an upstream issue, could you report it to them on
https://gitlab.gnome.org/GNOME/glib/issues ?

[Pablo Copissa (pcopissa)]

Reported upstream as issue 2062 (https://gitlab.gnome.org/GNOME/glib/issues/2062)