Nautilus unusably slow with large ~/.gvfs dirs

Bug #230374 reported by Gavin Hamill on 2008-05-14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gvfs (Ubuntu)
Ubuntu Desktop Bugs

Bug Description

Binary package hint: gvfs-fuse

Version: 0.2.3-0ubuntu5

Browsing dirs with many files (5000) is unusably slow with ~/.gvfs. Example:

cd; mkdir huge; cd huge
for i in `seq 1 5000`
 cp /etc/inputrc $i

Browsing to /home/gdh/huge with Nautilus takes 4 seconds. Great!

Adding a network share to sftp://localhost and browsing to sftp://localhost/home/gdh/huge takes 10 seconds. A bit slower as I'd expect - still perfectly acceptable.

Browsing to /home/gdh/.gvfs/sftp on localhost/home/gdh/huge takes 160 seconds. This is unusable.

gvfs-sftp uses ~27% , and gvfs-fuse-daemon uses ~10% during this final test.

I see the same behaviour with remote Samba shares, but using sftp to localhost eliminates network issues.

ProblemType: Bug
Architecture: i386
Date: Wed May 14 17:38:35 2008
DistroRelease: Ubuntu 8.04
ExecutablePath: /usr/bin/nautilus
NonfreeKernelModules: nvidia
Package: nautilus 1:2.22.2-0ubuntu5
PackageArchitecture: i386
SourcePackage: nautilus
Uname: Linux 2.6.24-17-generic i686

Gavin Hamill (gdh) wrote :
Sebastien Bacher (seb128) wrote :

thank you for your bug report. how do you browse those? do you have the issue using gvfs-ls? do using non gvfs fuse mounts has the same issue?

Changed in gvfs:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete
Gavin Hamill (gdh) wrote :

I am browsing by going Places -> Home Folder, then View -> Show Hidden Files and going into the .gvfs directory. From there I can select "gdh on localhost". I rely on ~/.gvfs to work with remote .rar and other large archive files with console / non-GNOME apps, since the 'unrar' console binary obviously has no idea what the "smb://" protocol is.

gvfs-ls is lightning-fast:

gdh@gdh-home:~$ time gvfs-ls sftp://gdh@localhost/home/gdh/huge >/dev/null

real 0m0.876s
user 0m0.104s
sys 0m0.016s

Because gvfs-ls is also able to provide directory listings of local files too, I tried this:

gdh@gdh-home:~$ time gvfs-ls /home/gdh/.gvfs/sftp\ on\ localhost/home/gdh/huge >/dev/null

real 0m7.977s
user 0m0.160s
sys 0m0.068s

So, 10 times slower to access trivial 'filename only' data using gvfs-ls.

I expect that Nautilus is several orders of magnitude slower because of all the extra metadata it will be requesting for each file.

I have tried disabling all the previews in Nautilus so that it doesn't count items in subdirs/generate icons for text-file, and 'Never' display preview for local files, but it's still taking minutes to show the contents of the 'huge' directory in ~/.gvfs/gdh on localhost/home/gdh/huge

It's purely access via gvfs-fuse-daemon that is slow, therefore the question about 'non gvfs fuse mounts' doesn't make much sense. (for completeness, my NTFS partitions via fuseblk run as fast as ext3).

Sebastien Bacher (seb128) wrote :

how do you know that's not the ssh fuse mounts which are slow and that's not a fuse issue? anyway maybe you could open the bug directly on where upstream is working, the ubuntu desktop team doesn't have the ressources to work on those design issues right now

Gavin Hamill (gdh) wrote :

Oh I see... Yes it's the same story with an smb mount. I've just been focusing on "sftp to localhost" since it eliminates network latency/packet loss as a potential cause.

I'll open upstream and link to here if I can.

Sebastien Bacher (seb128) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to 'New'. Thanks again!

Changed in gvfs:
status: Incomplete → Invalid
Changed in gvfs (Ubuntu):
status: Invalid → New
Changed in gvfs (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers