sshfsよりも高速にリモートファイルシステムをマウントできますか？

私はsshfsを使用してリモートで作業していましたが、特にEclipseを使用している場合は、非常に遅くて面倒です。

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

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

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

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

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

sshfs接続の速度を改善する必要がある場合は、次のオプションを試してください。

oauto_cache,reconnect,defer_permissions,noappledouble,nolocalcaches,no_readahead

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

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

完全に有効なSamba / NFSを使用する既に提案されたソリューションに加えて、オプションを提供することsshfsにより、より高速な暗号化（認証は通常と同じように安全ですが、転送されたデータ自体は解読しやすくなり-o Ciphers=arcfourます）へsshfs。マシンのCPUが弱い場合に特に役立ちます。

推奨する代替手段はありませんが、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で経験するボトルネックでもあります。

複数のフォルダーのリクエストを並行して行うことでこれを支援できますが、ほとんどのアプリはそれを行いません：先読みキャッシングを備えた低レイテンシのファイルシステム向けに設計されているため、1つのファイルの統計情報が完了するのを待ってから次のファイルに移動します。

プリキャッシング

しかし、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 &

これには明らかに時間がかかり、大量のデータを転送するため、巨大なキャッシュサイズが必要になります。しかし、それが完了すると、ファイルへのアクセスは快適に感じられるはずです。

SSHFSは（cpを実行するとき）ファイルの内容を転送する必要がない場合でも転送するため、本当に低速です。このアップストリームとDebianに報告しましたが、応答がありません：/

検索と試用後。私はちょうど-o Compression=noそれをたくさん追加する速度を見つけました。遅延は、圧縮および圧縮解除プロセスが原因で発生する場合があります。また、「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

NFSはより高速になります。ファイルシステムはどのくらい離れていますか？WAN経由の場合は、直接リモートアクセスするのではなく、単にファイルを前後に同期する方がよい場合があります。

大きなファイルがある場合は、NFSまたはSambaのいずれか。720p MoviesやがらくたのようなものでNFSを使用するのは本当にPITAです。Sambaはより良い仕事をします。他のいくつかの理由でSambaが嫌いなので、通常はお勧めしません。

小さいファイルの場合、NFSで十分です。

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

ルートとしてログインします。

「cd /」を使用して、最上位ディレクトリにアクセスします。

次に、マウントフォルダーが作成されていることを確認するか、「mkdir folder_name」を使用してマウントフォルダーを作成します。

その後、単に「mount xxxx：/ remote_mount_directory / local_mount_directory」を使用します。

すべてがうまく機能していれば、この前にマウントに成功するはずです。「exportfs」コマンドを使用して宛先ディレクトリーが検出できることを保証することにより、宛先ディレクトリーが共有されていることを確認して確認することができます。

お役に立てれば。これはlvie環境のものではなく、VMwareとFedora 16を使用してLAN上でテストされています。