maneira mais rápida de montar um sistema de arquivos remoto que o sshfs?

Eu tenho usado o sshfs para trabalhar remotamente, mas é realmente lento e irritante, principalmente quando uso o eclipse nele.

Existe alguma maneira mais rápida de montar o sistema de arquivos remoto localmente? Minha prioridade número 1 é a velocidade.

A máquina remota é o Fedora 15, a máquina local é o Ubuntu 10.10. Também posso usar o Windows XP localmente, se necessário.

O sshfs está usando o protocolo de transferência de arquivos SSH, o que significa criptografia.

Se você acabou de montar via NFS, é claro que é mais rápido, porque não criptografado.

você está tentando montar volumes na mesma rede? depois use o NFS .

Se você precisar melhorar a velocidade das conexões sshfs, tente estas opções:

oauto_cache,reconnect,defer_permissions,noappledouble,nolocalcaches,no_readahead

comando seria:

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

Além das soluções já propostas de uso do Samba / NFS, que são perfeitamente válidas, você também pode obter algum aumento de velocidade sshfsusando criptografia mais rápida (a autenticação seria tão segura como de costume, mas os dados transferidos seriam mais fáceis de descriptografar) fornecendo a -o Ciphers=arcfouropção para sshfs. É especialmente útil se sua máquina tiver CPU fraca.

Não tenho alternativas para recomendar, mas posso fornecer sugestões de como acelerar o sshfs:

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

Isso deve evitar algumas solicitações de ida e volta quando você está tentando ler conteúdo ou permissões para arquivos que você já recuperou anteriormente na sua sessão.

O sshfs simula exclusões e alterações localmente, portanto, as novas alterações feitas na máquina local devem aparecer imediatamente, apesar dos grandes tempos limite, pois os dados em cache são descartados automaticamente.

Mas essas opções não são recomendadas se os arquivos remotos puderem ser atualizados sem a máquina local saber, por exemplo, por um usuário diferente ou por um shell ssh remoto. Nesse caso, tempos limite mais baixos seriam preferíveis.

Aqui estão mais algumas opções com as quais experimentei, embora não tenha certeza se alguma delas fez alguma diferença:

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"

Você também deve verificar as opções recomendadas por Meetai em sua resposta.

Recursão

O maior problema no meu fluxo de trabalho é quando tento ler muitas pastas, por exemplo em uma árvore profunda, porque o sshfs executa uma solicitação de ida e volta para cada pasta separadamente. Esse também pode ser o gargalo que você experimenta com o Eclipse.

Fazer solicitações para várias pastas em paralelo pode ajudar nisso, mas a maioria dos aplicativos não faz isso: eles foram projetados para sistemas de arquivos de baixa latência com cache de leitura antecipada; portanto, esperam que uma estatística de arquivo seja concluída antes de passar para a próxima .

Precaching

Mas algo que o sshfs poderia fazer seria olhar para o futuro no sistema de arquivos remoto, coletar estatísticas de pastas antes de solicitá-las e enviá-las para mim quando a conexão não estiver imediatamente ocupada. Isso usaria mais largura de banda (a partir de dados de lookahead que nunca são usados), mas poderia melhorar a velocidade.

Podemos forçar o sshfs a fazer algum cache de leitura antecipada, executando-o antes de iniciar sua tarefa ou mesmo em segundo plano quando sua tarefa já estiver em andamento:

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

Isso deve pré-armazenar em cache todas as entradas do diretório, reduzindo parte da sobrecarga posterior de viagens de ida e volta. (Obviamente, você precisa usar os tempos limite grandes, como os fornecidos anteriormente, ou esses dados em cache serão limpos antes que o aplicativo os acesse.)

Mas isso findvai levar muito tempo. Como outros aplicativos, aguarda os resultados de uma pasta antes de solicitar a próxima.

Pode ser possível reduzir o tempo total solicitando que vários processos de localização procurem pastas diferentes. Não testei para ver se isso realmente é mais eficiente. Depende se o sshfs permite solicitações em paralelo. (Eu acho que sim.)

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 &

Se você também deseja pré-armazenar em cache o conteúdo do arquivo, tente o seguinte:

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

Obviamente, isso levará muito mais tempo, transferirá muitos dados e exige que você tenha um tamanho de cache enorme. Mas, quando terminar, o acesso aos arquivos deve ser agradável e rápido.

O SSHFS é muito lento porque transfere o conteúdo do arquivo, mesmo que não seja necessário (ao fazer o cp). Eu relatei isso a montante e ao Debian, mas nenhuma resposta: /

Depois de pesquisar e testar. Acabei de encontrar adicionar -o Compression=novelocidade muito. O atraso pode ser causado pelo processo de compactação e descompactação. Além disso, o uso de 'Ciphers = aes128-ctr' parece mais rápido do que outros, enquanto algum post fez algumas experiências sobre isso. Então, meu comando é de alguma forma assim:

sshfs -o allow_other, transform_symlinks, follow_symlinks, IdentityFile = / Users / maple / .ssh / id_rsa -o auto_cache, reconectar, defer_permissions -o Cifras = aes128-ctr -o Compressão = sem maple@123.123.123.123: / home / maple ~ / mntpoint

O NFS deve ser mais rápido. Quão remoto é o sistema de arquivos? Se estiver na WAN, é melhor sincronizar os arquivos para frente e para trás, em oposição ao acesso remoto direto.

NFS ou Samba, se você tiver arquivos grandes. Usar NFS com algo como filmes em 720p e porcaria é realmente uma PITA. O Samba fará um trabalho melhor, embora eu não goste do Samba por vários outros motivos e geralmente não o recomendo.

Para arquivos pequenos, o NFS deve estar bem.

Eu descobri que desligar o meu tema zsh, que estava verificando o status do arquivo git, ajudou imensamente - apenas entrar no diretório estava levando mais de 10 minutos. Da mesma forma, desabilite os verificadores de status do git no Vim.

Faça o login como root.

Acesse seu diretório de nível superior usando "cd /".

Em seguida, verifique se você possui uma pasta de montagem criada ou crie uma usando "mkdir folder_name".

Depois disso, basta usar "mount xxxx: / remote_mount_directory / local_mount_directory.

se tudo funcionou do seu lado, antes disso, você deve ter uma montagem bem-sucedida. Você pode verificar e garantir que o diretório de destino seja compartilhado usando o comando "exportfs" para garantir que eles possam ser encontrados.

Espero que isto ajude. Isso não é de um ambiente lvie, foi testado em uma LAN usando o VMware e o Fedora 16.