Browsing smb share is painfully slow

[Thomas Novin]

Binary package hint: gvfs

I would like to open a new bug with the same issue as bug #186461, browsing samba shares is painfully slow.

I don't notice this at home on my 100Mbit network with no so much directories but at work, over a 10Mbit leased line and hundreds of directories on a share, every operation takes 10-15 seconds until you get a bit deeper into the hierarchy inside a directory with only a couple of directories/files in it.

$ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04

$ dpkg -l | grep gvfs
ii gvfs 0.2.5-0ubuntu2 userspace virtual filesystem - server

[Thomas Novin (thomasn80)]

Tried it from a terminal instead of Nautilus and I have the problem there too.

$ cd .gvfs/
/.gvfs$ ls
myshare on winserver.domain.root
/.gvfs/myshare on winserver.domain.root$ time ls
(approx 700 directories and some files listed)
real 0m13.319s
user 0m0.012s
sys 0m0.008s
/.gvfs/myshare on winserver.domain.root$ time ls SomeDir
(5 files and 5 directories listed)
real 0m0.185s
user 0m0.004s
sys 0m0.008s
/.gvfs/myshare on winserver.domain.root$ time mkdir Testa

real 0m0.089s
user 0m0.000s
sys 0m0.004s

[Sebastien Bacher (seb128)]

thank you for your bug report, could you try if smbclient has the same issue?

[Thomas Novin (thomasn80)]

Test case 1: From Nautilus, I click the share which is saved to a bookmark. Then I go into one directory and two more steps up the hierarchy.

Time from start to completion: 40 seconds

Test case 2: With smbclient, connect to the share, issue 'ls', enter a directory, issue 'ls, then go two more steps up the hierarchy (ls'ing all the way).

Time from start to completion: 5 seconds (mostly typing took time)

I can also add that browsing to the same folder with Explorer in XP takes < 5 seconds.

[Sebastien Bacher (seb128)]

could you try if using gvfs-mount and gvfs-ls have the same issue?

[Thomas Novin (thomasn80)]

I don't know how to use those utils, both lack a man page..

$ man gvfs-ls
No manual entry for gvfs-ls
See 'man 7 undocumented' for help when manual pages are not available.
$ man gvfs-mount
No manual entry for gvfs-mount
See 'man 7 undocumented' for help when manual pages are not available.

I tried with gvfs-ls in /.gvfs/myshare on winserver.domain.root/ instead of ls and that was very slow, using time I can see the same result as with regular ls. Except that ls has a long delay then prints all the output fast and gvfs-ls shows the output almost as if you are connected on a terminal with 9600 bps :)

[David Coles (dcoles)]

I've run into this bug tonight. I was trying to access my smb home directory at the University. All the user's personal home directories are located under a single /Home share so there's quite a number of them. But even when you try and directly open the personal home directory (typing in the full URI) it seems to be doing some sort of "stat" operation on the parent directory (/Home). Wireshark show's many hundreds of FIND_NEXT2 requests going on (so it's certainly doing something!).

It works fine using the standard smbclient command and I've also just tried mounting it using gvfs-mount and gvfs-ls and that seems to be OK too (Shows the single directory in about 1/2 a second):

david@krikkit:~$ gvfs-mount smb://eigg.sms.ed.ac.uk/Home/sxxxxxx
david@krikkit:~$ gvfs-ls smb://eigg.sms.ed.ac.uk/Home/sxxxxxx
welcome

It seems fine right up until we try to list the parent directory:

david@krikkit:~$ gvfs-ls smb://eigg.sms.ed.ac.uk/Home/
# ... Very long wait...
# A block of a a dozen files or so appear approximately every 10 seconds...

Though from Wireshark we can see that it's dozens of files per second. Even after killing gvfs-ls the traffic continues. It's only after killing gvfsd-smb that it stops. I'm wondering if Nautilus for some reason enumerates the parent directory when you browse to it. That would certainly slow it down.

Also, upstream http://bugzilla.gnome.org/show_bug.cgi?id=549463 looks to be the same bug. (Those are the errors that I finally get from Nautilus if I wait long enough)

[Thomas Novin (thomasn80)]

Triagers, please set this bug to priority high since it makes samba usage almost useless for all users with lots of directories.

[Sebastien Bacher (seb128)]

thank you for the upstream bug reference

[squarooticus (krose)]

FWIW, I see the attached behavior when I try to browse a DAV share from an apache2 server.

On connect to the server, PROPFIND / is issued once with Depth 1. It takes a while, because this directory has over 1000 subdirectories. That's reasonable. Okay so far.

Then the weird stuff begins. When I click "311" (ignoring my taste in music for a moment), the *exact same* PROPFIND /311 with Depth 0 request is issued *twice* in a row over the same connection. Exactly the same headers, exactly the same result. I see other redundant requests, as well.

But then it gets *really* strange. After PROPFIND /311 with Depth 1 is issued, gvfs issues *another* PROPFIND / with Depth 1! In god's name, why? This appears to be the root of the slowdown I see: the needless repetition of requests for data that seconds before had been transferred. And I suspect the SMB gvfs backend is doing something similar.

Not sure if local caching + If-Modified-Since requests are valid here, but that may be a potential solution. Nautilus may be re-reading the parent directory unnecessarily; however, IMO the gvfs backend should be able to more gracefully deal with this situation, since not every application in existence can be rewritten to assume the data it is accessing is 20 mbits and 70 msec away. In my case, this is data that hardly ever changes: the only time the root directory of this DAV share changes is when I rip a new CD, which probably occurs once every few weeks.

(Aside: this stuff is even slower over GnuTLS SSL (16 seconds for PROPFIND / vs. about 2 seconds plaintext), the difference of which I can't yet explain since I can't tcpdump the SSL connection.)

My gvfs and related components are 0.2.5-0ubuntu2 (hardy up-to-date). My nautilus is 1:2.22.5.1-0ubuntu1 (also hardy up-to-date).

[Woonjas (woonjas)]

Ubuntu 16.04 still shows this behavior. :-(
Makes a very big argument against switching to Linux

[Jeroenst (h-maik-m)]

In Ubuntu 20.04 I get 11MB/s with mount.cifs and 10MB/s with gvfs.

I don't have a gigabit controller in this laptop so I can't test it for gigabit speeds at this moment, but it seems much better now.