Reported upstream as issue 2062
(https://gitlab.gnome.org/GNOME/glib/issues/2062)
** Bug watch added: gitlab.gnome.org/GNOME/glib/issues #2062
https://gitlab.gnome.org/GNOME/glib/issues/2062
** Description changed:
+ 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 3239804
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
- 5281631 10893
+ 5281631 10893
real 0m0,911s
user 0m0,003s
sys 0m0,005s
Factor is about 50.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1862264
Title:
Browsing smb share is painfully slow when mounted via "gio" (compared
with "mount")
Status in glib2.0 package in Ubuntu:
New
Bug description:
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 3239804
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 m