faster way to mount a remote file system than sshfs?

104,756

Solution 1

sshfs is using the SSH file transfer protocol, which means encryption.

If you just mount via NFS, it's of course faster, because not encrypted.

are you trying to mount volumes on the same network? then use NFS.

Solution 2

If you need to improve the speed for sshfs connections, try these options:

oauto_cache,reconnect,defer_permissions,noappledouble,nolocalcaches,no_readahead

command would be:

sshfs remote:/path/to/folder local -oauto_cache,reconnect,defer_permissions

Solution 3

Besides already proposed solutions of using Samba/NFS, which are perfectly valid, you could also achieve some speed boost sticking with sshfs by using quicker encryption (authentication would be as safe as usual, but transfered data itself would be easier to decrypt) by supplying -o Ciphers=arcfour option to sshfs. It is especially useful if your machine has weak CPU.

Solution 4

I do not have any alternatives to recommend, but I can provide suggestions for how to speed up sshfs:

sshfs -o cache_timeout=115200 -o attr_timeout=115200 ...

This should avoid some of the round trip requests when you are trying to read content or permissions for files that you already retrieved earlier in your session.

sshfs simulates deletes and changes locally, so new changes made on the local machine should appear immediately, despite the large timeouts, as cached data is automatically dropped.

But these options are not recommended if the remote files might be updated without the local machine knowing, e.g. by a different user, or a remote ssh shell. In that case, lower timeouts would be preferable.

Here are some more options I experimented with, although I am not sure if any of them made a differences:

sshfs_opts="-o auto_cache -o cache_timeout=115200 -o attr_timeout=115200   \
-o entry_timeout=1200 -o max_readahead=90000 -o large_read -o big_writes   \
-o no_remote_lock"

You should also check out the options recommended by Meetai in his answer.

Recursion

The biggest problem in my workflow is when I try to read many folders, for example in a deep tree, because sshfs performs a round trip request for each folder separately. This may also be the bottleneck that you experience with Eclipse.

Making requests for multiple folders in parallel could help with this, but most apps don't do that: they were designed for low-latency filesystems with read-ahead caching, so they wait for one file stat to complete before moving on to the next.

Precaching

But something sshfs could do would be to look ahead at the remote file system, collect folder stats before I request them, and send them to me when the connection is not immediately occupied. This would use more bandwidth (from lookahead data that is never used) but could improve speed.

We can force sshfs to do some read-ahead caching, by running this before you get started on your task, or even in the background when your task is already underway:

find project/folder/on/mounted/fs > /dev/null &

That should pre-cache all the directory entries, reducing some of the later overhead from round trips. (Of course, you need to use the large timeouts like those I provided earlier, or this cached data will be cleared before your app accesses it.)

But that find will take a long time. Like other apps, it waits for the results from one folder before requesting the next one.

It might be possible to reduce the overall time by asking multiple find processes to look into different folders. I haven't tested to see if this really is more efficient. It depends whether sshfs allows requests in parallel. (I think it does.)

find project/folder/on/mounted/fs/A > /dev/null &
find project/folder/on/mounted/fs/B > /dev/null &
find project/folder/on/mounted/fs/C > /dev/null &

If you also want to pre-cache file contents, you could try this:

tar c project/folder/on/mounted/fs > /dev/null &

Obviously this will take much longer, will transfer a lot of data, and requires you to have a huge cache size. But when it's done, accessing the files should feel nice and fast.

Solution 5

After searching and trial. I just found add -o Compression=no speed it a lot. The delay may be caused by the compression and uncompression process. Besides, use 'Ciphers=aes128-ctr' seems faster than others while some post has done some experiments on this. Then, my command is somehow like this:

sshfs -o allow_other,transform_symlinks,follow_symlinks,IdentityFile=/Users/maple/.ssh/id_rsa -o auto_cache,reconnect,defer_permissions -o Ciphers=aes128-ctr -o Compression=no [email protected]:/home/maple ~/mntpoint

Share:
104,756

Related videos on Youtube

CuriousMind
Author by

CuriousMind

Updated on September 18, 2022

Comments

  • CuriousMind
    CuriousMind over 1 year

    I have been using sshfs to work remotely, but it is really slow and annoying, particularly when I use eclipse on it.

    Is there any faster way to mount the remote file system locally? My no.1 priority is speed.

    Remote machine is Fedora 15, local machine is Ubuntu 10.10. I can also use Windows XP locally if necessary.

  • Ivangrx
    Ivangrx about 11 years
    It's not slow because of the encryption, it's slow because it's FUSE and it keeps checking the file system state.
  • Sparhawk
    Sparhawk over 10 years
    -oCipher=arcfour made no difference in my tests with a 141 MB file created from random data.
  • Sparhawk
    Sparhawk over 10 years
    That's because there were multiple typos in the command. I've edited it. I noticed a 15% speedup from my raspberry pi server. (+1)
  • Sparhawk
    Sparhawk over 10 years
    @w00t I don't think that it's FUSE slowing it down, and not the encryption. Changing the encryption to arcfour sped it up for me, whereas using scp was just as slow as sshfs.
  • Ivangrx
    Ivangrx over 10 years
    @Sparhawk there's a difference between throughput and latency. FUSE gives you pretty high latency because it has to check the filesystem state a lot using some pretty inefficient means. arcfour gives you good throughput because the encryption is simpler. In this case latency is most important because that's what causes the editor to be slow at listing and loading files.
  • Sparhawk
    Sparhawk over 10 years
    @w00t. Ah okay. Good points.
  • Mathieu Rodic
    Mathieu Rodic over 9 years
    Thanks, worked for me! Had to remove defer_permissions though (unknown option).
  • earthmeLon
    earthmeLon about 9 years
    Won't nolocalcaches decrease performance by forcing lookups every operation? Does this contradict auto_cache?
  • Mantriur
    Mantriur over 8 years
    The way I read the docs, nolocalcaches only disables the kernel side of things, sshfs still has its own cache. I could imagine that the kernel level checks are tuned for "real" file systems and as such more extensive. On the sshfs side "cache_timeout" looks promising, too. Here's a list: saltycrane.com/blog/2010/04/notes-sshfs-ubuntu ... lots of good stuff. :-)
  • Mantriur
    Mantriur over 8 years
    nolocalcaches and defer_permissions don't seem valid (anymore?) on Debian Jessie.
  • Mantriur
    Mantriur about 8 years
    I find that "kernel_cache" is faster than "auto_cache", but afaik it assumes exclusive access, so only use it if nothing else is changing that data.
  • studgeek
    studgeek almost 8 years
    Why no_readahead?
  • joeytwiddle
    joeytwiddle almost 8 years
    It is efficient with mv. Unfortunately when you run cp locally, FUSE only sees requests to open files for reading and writing. It does not know that you are making a copy of a file. To FUSE it looks no different from a general file write. So I fear this cannot be fixed unless the local cp is made more FUSE-aware/FUSE-friendly. (Or FUSE might be able to send block hashes instead of entire blocks when it suspects a cp, like rsync does, but that would be complex and might slow other operations down.)
  • ManuelSchneid3r
    ManuelSchneid3r over 7 years
    What do you mean by "oauto_cache"?
  • TimSC
    TimSC over 6 years
    The [email protected] cipher is also an option worth considering now arcfour is obsolete. Chacha20 is faster on ARM processors than AES but far worse on x86 processors with AES instructions (which all modern desktop CPUs have as standard these days). klingt.net/blog/ssh-cipher-performance-comparision You can list supported ciphers with "ssh -Q cipher"
  • Elijah Lynn
    Elijah Lynn over 6 years
    Removed 'defer_permission' as I think that is mac specifid, no linux.
  • Abandoned Cart
    Abandoned Cart about 5 years
    @ManuelSchneid3rI know it's a bit late, but it's the same as -o auto_cache because the argument and parameters do not need to be spaced.
  • Dmitri Pisarev
    Dmitri Pisarev almost 5 years
    Wow, this is a really good tip!
  • LewlSauce
    LewlSauce over 4 years
    On Mac OS X Catalina, the local folder just disappears when it gets mounted and you can't see anything in it when trying to ls it. "No such file or directory". unmount it and then the folder becomes visible again. Any thoughts?
  • ThankYee
    ThankYee over 4 years
    The defer_permissions option fixes some issues on translating filesystem permissions when mounting SSH filesystem from Mac OS, but the option does not exist in Linux.
  • Mikko Rantalainen
    Mikko Rantalainen about 4 years
    If you want to read file contents to get it into cache the wc -l is pretty good. It just counts occurrences of 0x10 in the file so it simply reads the file once without outputting the contents.
  • skyrail
    skyrail about 4 years
    most of options above are unknown on debian wheezy for seagate dockstar. only no_readahead and kernel_cache is accepted. kernel_cache seems to bring more stability in data transfer to ssd but I get same speed as before. I have this in fstab: sshfs#home@win10_host:/users /mnt/ssh/win10_host fuse reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,uid=0‌​,gid=0,umask=0,allow‌​_other,auto,ssh_comm‌​and=sshpass\040-f\04‌​0/root/.ssh/mydevice‌​.password\040ssh,no_‌​readahead,kernel_cac‌​he 0 0
  • Mikko Rantalainen
    Mikko Rantalainen over 3 years
    I think NFS traffic can be transferred over SSH pipe so that should result in the best performance if you can use NFS on the remote localhost. The problem with sshfs is that's technically running SFTP and fuse just pretends to be a POSIX compatible filesystem over that protocol. The SFTP protocol doesn't support any fancy features and as a result, any protocol over that will end up having pretty poor overall performance. If you replace SFTP with NFS and keep encryption, it will be much faster.
  • Emile 81
    Emile 81 about 3 years
    Yes, this was the one, thanks!
  • Fuseteam
    Fuseteam almost 3 years
    fun enough Compression=yes seems to speed it up for me while all the others didn't seem to make a difference
  • MasterScrat
    MasterScrat over 2 years
    This is not doable anymore as the fastest ciphers (eg arcfour) have now been permanently removed from recent SSH versions
  • Community
    Community about 2 years
    As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
  • Ravindra Bawane
    Ravindra Bawane about 2 years
    This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review