リモートで作業するためにsshfsを使っていますが、特にeclipseを使っているときは本当に遅くてイライラします
リモートファイルシステムをローカルにマウントするより速い方法はありますか？私のNo.1の優先順位はスピードです
リモートマシンはFedora 15、ローカルマシンはUbuntu 10.10。必要に応じてローカルでWindows XPも使えるようにしています
80 Vendetta 2011-10-08
sshfsはSSHのファイル転送プロトコル、つまり暗号化を利用しています
暗号化されていないので、NFS経由でマウントするだけなら、もちろんその方が速いです
同じネットワーク上にボリュームをマウントしようとしていますか？
18 Tilo 2011-10-08
sshfs 接続の速度を向上させる必要がある場合は、以下のオプションを試してみてください
oauto_cache,reconnect,defer_permissions,noappledouble,nolocalcaches,no_readahead
コマンドになります
sshfs remote:/path/to/folder local -oauto_cache,reconnect,defer_permissions
48 Meetai.com 2014-06-24
Samba/NFSを使うという既に提案されている解決策は完全に有効であるが、sshfsに-o Ciphers=arcfourオプションを与えることで、より速い暗号化(認証は通常通り安全だが、転送されたデータ自体はより簡単に復号化される)を使うことで、sshfsに固執して速度を向上させることもできる。これは特にCPUの弱いマシンでは便利です
20 aland 2012-05-30
代替案はありませんが、sshfsを高速化する方法を提案します
sshfs -o cache_timeout=115200 -o attr_timeout=115200 ...
これにより、コンテンツを読もうとしているときや、セッションですでに取得したファイルのパーミッションを読もうとしているときに、往復のリクエストが発生するのを避けることができるはずです
sshfs はローカルでの削除と変更をシミュレートするので、キャッシュされたデータが自動的に削除されるため、大きなタイムアウトにもかかわらず、ローカルマシン上で行われた新しい変更はすぐに表示されるはずです
しかし、リモートファイルがローカルマシンに知られずに更新される可能性がある場合、例えば別のユーザやリモートの ssh シェルによって更新される可能性がある場合、これらのオプションは推奨されません。その場合は、より低いタイムアウトが望ましいでしょう
ここでは、私が実験したオプションをいくつかご紹介します
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"
また、Meetaiさんの回答の中にあるMeetaiさんおすすめのオプションもチェックしてみてください
Recursion
私のワークフローで一番問題になるのは、例えば深いツリーなどで多くのフォルダを読もうとしたときに、sshfs が各フォルダに対して個別に往復リクエストを行うためです。これもEclipseで経験したボトルネックかもしれません
複数のフォルダへのリクエストを並行して行うことで、この問題を解決することができますが、ほとんどのアプリはこれを行いません
Precaching
しかし、sshfs ができることは、リモートのファイルシステムを先読みして、私がリクエストする前にフォルダの統計情報を収集し、接続がすぐに使用されていないときに私に送ることです。これはより多くの帯域幅を使うことになりますが (決して使われないルックヘッドデータから)、 速度を向上させることができます
タスクを開始する前にこれを実行したり、タスクがすでに進行中のときにバックグラウンドで実行したりすることで、sshfs に先読みキャッシュを強制的に実行させることができます
find project/folder/on/mounted/fs > /dev/null &
これにより、すべてのディレクトリ エントリがプリキャッシュされ、ラウンド トリップによる後のオーバーヘッドの一部が軽減されます（もちろん、以前に提供したような大きなタイムアウトを使用する必要があります。(もちろん、私が以前に提供したような大きなタイムアウトを使用する必要があります。そうでなければ、このキャッシュされたデータはアプリがアクセスする前にクリアされます)
しかし、そのfindは時間がかかります。他のアプリのように、1つのフォルダの結果を待ってから次のフォルダをリクエストします
複数の検索プロセスに別のフォルダを調べるように依頼することで、全体の時間を短縮できるかもしれません。これが本当に効率的かどうかはテストしていません。sshfs が並列リクエストを許可しているかどうかにもよります。(私はそう思っています)
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 &
また、ファイルの内容を事前にキャッシュしておきたい場合は、以下のようにしてみてはいかがでしょうか
tar c project/folder/on/mounted/fs > /dev/null &
これは明らかに時間がかかり、多くのデータを転送し、巨大なキャッシュサイズを必要とします。しかし、それが完了したときに、ファイルへのアクセスは素晴らしく高速に感じられるはずです
14 joeytwiddle 2015-08-22
検索して試した結果add -o Compression=no でかなり速くなることがわかりました。遅延は圧縮と解凍の処理によるものかもしれません。また、postで実験したところ、Ciphers=aes128-ctrを使った方が速いようです。そして、私のコマンドはなんとなくこんな感じです
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 maple@123.123.123.123:/home/maple ~/mntpoint
5 maple 2018-09-20
SSHFS は、必要がなくても (cp を実行しているときに) ファイルの内容を転送してしまうので、本当に遅いです。このことを上流とDebianに報告しましたが、応答はありませんでした
4 Daniel Milde 2012-05-30
私のzshテーマがgitファイルの状態をチェックしていたのをオフにすると、とても助かることがわかりました。ディレクトリを入力するだけで10分以上かかっていたのですが、同様にVimのgit status checkersをオフにしてみました
4 bloke_zero 2019-07-10
NFSの方が速いはずです。ファイルシステムはどのくらいリモートにあるのか？WAN 経由であれば、直接リモートアクセスするのではなく、ファイルを前後に同期させるだけの方が良いかもしれません
2 Adam Wagner 2011-10-08
大きなファイルがある場合は、NFSかSambaのどちらか。720pの映画やガラクタのようなものでNFSを使用するのは本当にPITAです。Sambaはより良い仕事をするだろう、しかし私は他の理由の数のためにSambaを嫌い、私は通常それをお勧めしないだろう
小さなファイルの場合は、NFSで問題ないはずです
1 Franz Bettag 2011-10-08
私はプレーンなSFTPを使っています。主に不要な認証をカットするためにそれをしましたが、私は暗号化の層をドロップすることも助けになることを確信しています。(はい、ベンチマークをする必要があります)
ここでは、些細な使い方を記述します。https://www.quora.com/How-can-I-use-SFTP-without-the-overhead-of-SSH-I-want-a-fast-and-flexible-file-server-but-I-dont-need-encryption-or-authentication
0 Kyler Laird 2020-06-11
rootでログインします
トップレベルのディレクトリにアクセスするには、”cd /” でアクセスします
その後、マウントフォルダが作成されているか、”mkdir folder_name “を使用して作成されていることを確認してください
その後は「mount x.x.x.x:/remote_mount_directory /local_mount_directory」を使用するだけです
もしあなたの側ですべてがうまくいっていれば、この前にマウントが成功しているはずです。exportfs” コマンドを使って、マウント先のディレクトリが共有されているかどうか確認してみてください
これが役立つことを願っています。これはlvie環境ではなく、VMwareとFedora 16を使用してLAN上でテストしました
-4 JasonN 2013-02-04
