Eu tenho usado o sshfs para trabalhar remotamente, mas é muito lento e chato, particularmente quando eu uso eclipse nele.
Existe alguma maneira mais rápida de montar o sistema de arquivos remoto localmente? Minha prioridade no.1 é a velocidade.
A máquina remota é o Fedora 15, a máquina local é o Ubuntu 10.10. Eu também posso usar o Windows XP localmente, se necessário.
Se você precisar melhorar a velocidade das conexões sshfs, tente estas opções:
oauto_cache,reconnect,defer_permissions,noappledouble,nolocalcaches,no_readahead
o comando seria:
sshfs remote:/path/to/folder local -oauto_cache,reconnect,defer_permissions
Além das soluções já propostas de usar o Samba / NFS, que são perfeitamente válidas, você também pode aumentar a velocidade com sshfs usando criptografia mais rápida (a autenticação seria tão segura como de costume, mas os dados transferidos em si seriam mais fáceis descriptografar) fornecendo a opção -o Ciphers=arcfour para sshfs . É especialmente útil se sua máquina tiver CPU fraca.
Eu não tenho alternativas para recomendar, mas posso fornecer sugestões sobre 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 em sua sessão.
sshfs simula exclusões e alterações localmente, portanto, novas alterações feitas na máquina local devem aparecer imediatamente, apesar dos grandes tempos limite, já que 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 o conhecimento da máquina local, por exemplo, por um usuário diferente ou um shell ssh remoto. Nesse caso, tempos limites menores seriam preferíveis.
Aqui estão mais algumas opções que experimentei, embora não tenha certeza se alguma delas fez 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 recomendado por Meetai em sua resposta.
O maior problema no meu fluxo de trabalho é quando tento ler muitas pastas, por exemplo, em uma árvore profunda, porque o sshfs realiza 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, então aguardam a conclusão de uma estatística antes de continuar para o próximo.
Mas algo que o sshfs poderia fazer seria olhar para frente no sistema de arquivos remoto, coletar estatísticas de pasta antes de solicitá-las e enviá-las para mim quando a conexão não for imediatamente ocupada. Isso usaria mais largura de banda (a partir de dados lookahead que nunca são usados), mas poderia melhorar a velocidade.
Podemos forçar o sshfs a fazer algum cache de leitura antecipada, executando isso antes de começar 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 de diretório, reduzindo algumas das sobrecargas posteriores das viagens de ida e volta. (É claro que você precisa usar os tempos limite grandes, como os que forneci anteriormente, ou esses dados armazenados em cache serão limpos antes que o seu aplicativo os acesse).
Mas esse find demorará muito tempo. Como outros aplicativos, ele aguarda os resultados de uma pasta antes de solicitar a próxima.
Pode ser possível reduzir o tempo geral solicitando vários processos de localização para examinar pastas diferentes. Eu 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 quiser armazenar em cache o conteúdo do arquivo, tente isso:
tar c project/folder/on/mounted/fs > /dev/null &
Obviamente, isso levará muito mais tempo, transferirá muitos dados e exigirá que você tenha um tamanho de cache enorme. Mas quando estiver pronto, 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 no upstream e no Debian, mas sem resposta: /
O NFS deve ser mais rápido. Quão remoto é o sistema de arquivos? Se estiver na WAN, talvez seja melhor sincronizar os arquivos, ao contrário do acesso remoto direto.
NFS ou Samba, se você tiver arquivos grandes. Usando NFS com algo como 720p Movies e porcaria é realmente um PITA. O Samba fará um trabalho melhor, embora eu não goste do Samba por várias outras razões e eu normalmente não o recomendaria.
Para arquivos pequenos, o NFS deve estar bem.
Depois de pesquisar e testar. Acabei de encontrar adicionar -o Compression=no velocidade muito. O atraso pode ser causado pelo processo de compactação e descompactação. Além disso, use 'Ciphers = aes128-ctr' parece mais rápido do que outros enquanto alguns postam 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,reconnect,defer_permissions -o Ciphers=aes128-ctr -o Compression=no [email protected]:/home/maple ~/mntpoint
Faça login como root.
Acesse seu diretório de nível superior usando "cd /".
Em seguida, verifique se você tem uma pasta de montagem criada ou crie uma usando "mkdir folder_name".
Depois disso, simplesmente use "mount x.x.x.x: / remote_mount_directory / local_mount_directory.
se tudo funcionou do seu jeito, antes disso, você deve ter uma montagem bem-sucedida. Você pode querer verificar e certificar-se de que o diretório de destino seja compartilhado usando o comando "exportfs" para garantir que eles possam ser encontrados.
Espero que isso ajude. Este não é de um ambiente lvie, ele foi testado em uma LAN usando o VMware e o Fedora 16.
Tags nfs sshfs remote linux filesystems