web-dev-qa-db-ja.com

sshfsよりもリモートファイルシステムをマウントするより速い方法は？

私はsshfsを使ってリモートで作業してきましたが、特にEclipseを使っている場合は本当に遅くて厄介です。

リモートファイルシステムをローカルにマウントするためのもっと速い方法はありますか？私の一番の優先事項はスピードです。

リモートマシンはFedora 15、ローカルマシンはUbuntu 10.10です。必要に応じて、Windows XPをローカルで使用することもできます。

linuxfilesystemsremotenfssshfs
68
CodeNoob

sshfsはSSHファイル転送プロトコルを使用しています。これは暗号化を意味します。

NFS経由でマウントしただけの場合は、暗号化されていないので、もちろん高速です。

同じネットワークにボリュームをマウントしようとしていますか？それからNFSを使用します。

14
Tilo

Sshfs接続の速度を上げる必要がある場合は、以下のオプションを試してください。

oauto_cache,reconnect,defer_permissions,noappledouble,nolocalcaches,no_readahead

コマンドは次のようになります。

sshfs remote:/path/to/folder local -oauto_cache,reconnect,defer_permissions
39
Meetai.com

Samba/NFSを使うというすでに提案されている解決策の他に、完全に有効なものに加えて、より速い暗号化を使うことでsshfsに固執するスピードブーストを達成できます。 -o Ciphers=arcfourオプションからsshfsへ。あなたのマシンが弱いCPUを持っているなら、それは特に役に立ちます。

18
aland

私には他に推奨できる方法はありませんが、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が推奨するオプション をチェックするべきです。

再帰

私のワークフローにおける最大の問題は、sshfsが各フォルダーに対して個別にラウンドトリップ要求を実行するため、たとえば深いツリー内で多数のフォルダーを読み取ろうとしたときです。これはEclipseで発生するボトルネックかもしれません。

複数のフォルダを並行してリクエストすることでこれを解決することはできますが、ほとんどのアプリはそうはしません。先読みキャッシュを備えた待ち時間の短いファイルシステム用に設計されています。 。

予言

しかし、sshfsができることは、リモートファイルシステムを先読みし、要求する前にフォルダの統計情報を収集し、すぐに接続が使用されていないときに送信することです。これは（決して使用されない先読みデータからの）より多くの帯域幅を使用しますが、速度を向上させることができます。

タスクを開始する前に、あるいはタスクが既に進行中の場合はバックグラウンドで実行することで、sshfsに先読みキャッシュを強制的に実行させることができます。

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

これにより、すべてのディレクトリエントリがプリキャッシュされ、ラウンドトリップによるその後のオーバーヘッドの一部が軽減されます。 （もちろん、先ほど提供したような大きなタイムアウトを使用する必要があります。そうしないと、このキャッシュされたデータはアプリケーションがアクセスする前にクリアされます。）

しかし、そのfindは長い時間がかかります。他のアプリと同じように、あるフォルダからの結果を待ってから次のフォルダを要求します。

複数の検索プロセスに異なるフォルダーを調べるように依頼することで、全体の時間を短縮することが可能かもしれません。これが本当に効率的かどうかを確認するためのテストは行っていません。 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 &

明らかにこれにはもっと時間がかかり、大量のデータを転送し、そして巨大なキャッシュサイズが必要です。しかし、それが終わったら、ファイルへのアクセスはすばやくいい感じになるはずです。

9
joeytwiddle

SSHFSは、ファイルの内容を転送しなくても転送するので（cpを実行するとき）、本当に遅いです。私はこれを上流やDebianに報告しましたが、返答はありません：/

4
Daniel Milde

検索して試した後。私はadd -o Compression=noがそれを非常に速くするのを発見したところです。この遅延は、圧縮および圧縮解除プロセスによって引き起こされる可能性があります。そのうえ、 'Ciphers = aes128-ctr'を使うのは他のものより速いようですが、いくつかの 投稿 はこれに関していくつか実験をしました。それで、私の命令はどういうわけかこのようになります：

sshfs -o allow_other、transform_symlinks、follow_symlinks、IdentityFile = /ユーザー/ maple/.ssh/id_rsa -o auto_cache、再接続、defer_permissions -o暗号= aes128-ctr -o圧縮= no [email protected]：/ home/maple〜/mntpoint

3
maple

NFSはもっと速いはずです。ファイルシステムはどのくらい離れていますか？ WAN経由の場合は、直接リモートアクセスするのではなく、ファイルを前後に同期させるだけのほうがよいでしょう。

2
Adam Wagner

大きなファイルがある場合は、NFSまたはSambaのどちらかです。 720pの映画やがらくたのようなものでNFSを使用することは本当にPITAです。 Sambaはもっと良い仕事をするだろう、それ以外にもたくさんの理由でSambaが好きではないので、通常はお勧めしません。

小さなファイルの場合は、NFSで問題ありません。

1
Franz Bettag

Gitファイルのステータスをチェックしているzshテーマをオフにすると非常に役立ちました。ディレクトリに入るだけで10分以上かかりました。同様に、Vimでgitステータスチェッカーをオフにします。

1
bloke_zero