GNOME Bugzilla – Bug 512472
gvfs painfully slow over smb (samba)
Last modified: 2008-04-25 21:38:36 UTC
Hi! I'm trying the gvfs code in Ubuntu hardy (where it is now default). I'm pretty annoyed by the smb performance. I have a Debian-based NAS on my LAN, that usually gives around 2-3 Mb/s transfer speeds, using kernel (cifs) mounts. Accessing the share using smb:/// in nautilus gives me about 300 kb/s, or about a tenth of the speed. I've tried measuring using command-line and the FUSE .gvfs/mountpoint/... - and the results are the same, meaning that it is not nautilus' fault. I really hope this is an issue that can be fixed, as I think gvfs is shaping up nicely! Let me know if I can help debug.
What did you use to get with gnome-vfs? Implementing bug 509619 would help with the performance, but there could be other issues leading to the slow performance too. It requires some profiling.
Well, readahead doesn't help on write, now does it :-) I've tried cifs with directio, and still get similar ~10x better performance. Unfortunately, I can't tell you how I fared with gnome-vfs as I just installed my NAS. Is there a simple (command-line) method of using gnome-vfs to test this? I'll see what I can do when I get home.
You can try timing gnomevfs-cat smb://host/share/dir/file.txt > /dev/null
Ok, here are a few interesting figures: (on a fresh gvfs-mount'd volume) gvfs-cat smb://192.168.0.15/media/Mediastorage/random.bin > random.bin 14.233s (using the gvfs-fuse mount) cp /home/mini/.gvfs/media\ on\ 192.168.0.15/Mediastorage/random.bin . 3.128s (using a "mount -t cifs" mount) cp /mnt/slug/Mediastorage/random.bin . 4.139s gnomevfs-cat smb://192.168.0.15/media/Mediastorage/random.bin > random.bin 1m42.575s nautilus drag & drop from gvfs mount on desktop 44.546s nautilus drag and from from .gvfs 6.811s !! The figures are repeatable. One reason for the slugginess could be that the samba server seems to take up 80% or so of the CPU on the NSLU2 it's running on. It's only a 266MHz ARM machine, so... my conclusion is that gvfs via nautilus somehow makes the samba server work verrry hard, much harder than over fuse. The other observation is that I tried the above over wireless and wired (100mbps, full duplex, I did check), and the difference was minimal (the wireless was maybe 20-30% slower in all cases). Ideas?
Oh, that was a 10MiB (exactly) file.
Its kinda weird that copying via fuse is faster than gvfs-cat, as it should be using the same codepaths. Can you also time: gvfs-cat smb://192.168.0.15/media/Mediastorage/random.bin > /dev/null gvfs-copy smb://192.168.0.15/media/Mediastorage/random.bin .
> gvfs-cat smb://192.168.0.15/media/Mediastorage/random.bin > /dev/null 16.577s (close to above gvfs-cat, takes 16s today too) > gvfs-copy smb://192.168.0.15/media/Mediastorage/random.bin . 16.398s
Then how the heck can the gvfs fuse mount be faster? Did that really successfully copy the file?
I did some research on this (using the sftp backend which had similar discrpancies) and the reason it happens is because you get larger read requests via the fuse backend. So, I implemented part of readahead (i.e. request data in large chunks), and it basically killed the difference between the fuse and gvfs-copy case. It also brought gvfs-copy time to about the same as scp, which seems good. Mikael, can you redo your tests with gvfs updated to the following commit: (make sure the gvfsd-smb process for the mount is restarted) 2008-02-01 Alexander Larsson <alexl@redhat.com> * daemon/gvfsreadchannel.c: Request larger buffers than the client requested so for better network efficiency. (#512472)
Just a heads up that I won't be able to test this patch for at least a month. The explanation is fully plausible, though.
I see that this bug has not been closed. It seems my issues have been fixed (I'm on Hardy now). gvfs-cat smb://slug/media/Mediastorage/random.bin > random.bin 4.960s cp /home/mini/.gvfs/media\ på\ slug/Mediastorage/random.bin . 4.960s nautilus drag & drop from gvfs mount on desktop 5.006s etc... So, all well now, thanks for the good work and closing the bug!