After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 785074 - Slow directory listing with gvfs-smb
Slow directory listing with gvfs-smb
Status: RESOLVED OBSOLETE
Product: gvfs
Classification: Core
Component: fuse
1.32.x
Other Linux
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2017-07-18 14:52 UTC by Laurențiu Nicola
Modified: 2018-09-21 18:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Script to create test file tree for copy performance measurement (379 bytes, text/x-python)
2017-12-21 23:03 UTC, Francis Giraldeau
Details

Description Laurențiu Nicola 2017-07-18 14:52:01 UTC
Possibly related to #543640 although I'm seeing about the same thing with "gio list" and ls.

Directory enumeration (when running ls, browsing from nautilus etc.) is very slow. ls calls lstat on each file. Wireshark shows that gvfs-smb is using SMB2, but does a Create/GetInfo/Close sequence on each lstat() call. ls -l takes 11 seconds for a 500-file directory, gio ls takes 8 seconds but does the same calls.

mount.cifs defaults to SMB1 and uses FIND_NEXT2 for lstat and QUERY_PATH_INFO for getxattr. With that, ls takes 100 ms and ls -l takes 3s.

mount.cifs -o vers=3.0 uses SMB2_FIND_ID_FULL_DIRECTORY_INFO. With that, ls takes around 80 ms and ls -l around 100 ms, but the difference is probably in the time it takes to display the output.
Comment 1 Laurențiu Nicola 2017-07-18 15:26:18 UTC
Looking at initiate_cifs_search() and cifs_filldir() in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/fs/cifs/readdir.c it seems that the kernel driver preloads the information for the directory entries.
Comment 2 Francis Giraldeau 2017-12-21 23:03:41 UTC
Created attachment 365858 [details]
Script to create test file tree for copy performance measurement
Comment 3 Francis Giraldeau 2017-12-21 23:20:08 UTC
I observed the same slowdown. I added a small script that creates a file tree for measuring the performance. Each file is very small. On average, 4 files per seconds are transfered.

I saw also numerous redundant SMB2 requests in the tcpdump logs (altough, that test eas done with gvfs-fuse). Gvfs checks if the file is a directory, gets all the meta info, does that for every directory from the mount base to the file, if the file already exists it create a temporary file and move the file once the transfer is done. Each of these request takes 7ms to complete on my file server and these delays add up quickly.
Comment 4 Ondrej Holy 2018-01-03 09:48:32 UTC
GVfs won't ever be equally fast as CIFS kernel client. But "gio copy" can approximate to speed of smbclient. How fast is "smbclient -c ls" in comparison to "gio copy"? We can't do much with redundant requests from clients FUSE...
Comment 5 Laurențiu Nicola 2018-01-03 10:21:28 UTC
This issue wasn't about the overhead of FUSE, but about the protocol implementation. I think the kernel driver prefetches information about the directory contents when it open, and then returns the cached results. Or this is what I remember, at least. GVfs is much more chatty.

> How fast is "smbclient -c ls" in comparison to "gio copy"?

If you meant "gio list":

gio list [...] 0.09s user 0.01s system 0% cpu 1:12.21 total
smbclient [...] 0.07s user 0.01s system 16% cpu 0.483 total

on the same directory of ~3200 files.
Comment 6 GNOME Infrastructure Team 2018-09-21 18:08:09 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/306.