moyen plus rapide de monter un système de fichiers distant que sshfs?

72

J'utilise sshfs pour travailler à distance, mais c'est vraiment lent et ennuyeux, en particulier lorsque j'utilise eclipse dessus.

Existe-t-il un moyen plus rapide de monter le système de fichiers distant localement? Ma priorité n ° 1 est la vitesse.

La machine distante est Fedora 15, la machine locale est Ubuntu 10.10. Je peux également utiliser Windows XP localement si nécessaire.

Vendetta
la source

Réponses:

14

sshfs utilise le protocole de transfert de fichiers SSH, ce qui signifie le cryptage.

Si vous montez simplement via NFS, c'est bien sûr plus rapide, car non crypté.

essayez-vous de monter des volumes sur le même réseau? puis utilisez NFS .

Tilo
la source
35
Ce n'est pas lent à cause du chiffrement, mais parce qu'il s'agit de FUSE et qu'il continue de vérifier l'état du système de fichiers.
w00t
3
@ w00t Je ne pense pas que FUSE le ralentisse, pas le cryptage. Changer le cryptage à arcfour l'a accéléré, alors que l'utilisation scpétait aussi lente que sshfs.
Sparhawk
21
@Sparhawk, il existe une différence entre le débit et la latence. FUSE vous donne un temps de latence assez élevé car il doit vérifier l’état du système de fichiers à l’aide de moyens peu efficaces. arcfour vous donne un bon débit car le cryptage est plus simple. Dans ce cas, la latence est primordiale car c’est la raison pour laquelle l’éditeur tarde à lister et à charger les fichiers.
w00t
3
@ w00t. Ah ok. Bons points.
Sparhawk
41

Si vous devez améliorer la vitesse pour les connexions sshfs, essayez ces options:

oauto_cache,reconnect,defer_permissions,noappledouble,nolocalcaches,no_readahead

commande serait:

sshfs remote:/path/to/folder local -oauto_cache,reconnect,defer_permissions
Meetai.com
la source
1
Merci, a travaillé pour moi! J'ai dû enlever defer_permissionscependant (option inconnue).
Mathieu Rodic
4
Ne nolocalcaches diminuerez-vous pas les performances en forçant les recherches à chaque opération? Est-ce que cela contredit auto_cache?
earthmeLon
2
nolocalcaches et defer_permissions ne semblent pas valables (plus?) sur Debian Jessie.
Quelqu'un
4
Pourquoi no_readahead?
studgeek
1
Qu'entendez-vous par "oauto_cache"?
ManuelSchneid3r
18

En plus des solutions déjà proposées d’utilisation de Samba / NFS, qui sont parfaitement valables, vous pouvez également gagner du temps sshfsen utilisant un cryptage plus rapide (l’authentification serait aussi sûre que d’habitude, mais les données transférées seraient plus faciles à décrypter) en fournissant une -o Ciphers=arcfouroption. à sshfs. Cela est particulièrement utile si votre ordinateur a un processeur faible.

un terrain
la source
-oCipher=arcfourfait aucune différence dans mes tests avec un fichier de 141 Mo créé à partir de données aléatoires.
Sparhawk
6
C'est parce qu'il y avait plusieurs fautes de frappe dans la commande. Je l'ai édité. J'ai remarqué une accélération de 15% de mon serveur pi framboise. (+1)
Sparhawk le
4
Le chiffrement [email protected] est également une option à considérer, car arcfour est obsolète. Chacha20 est plus rapide sur les processeurs ARM que sur AES, mais bien pire sur les processeurs x86 avec instructions AES (que tous les processeurs de bureau modernes ont en standard de nos jours). klingt.net/blog/ssh-cipher-performance-comparision Vous pouvez lister les chiffrements supportés avec "ssh -Q cipher"
TimSC
11

Je n'ai aucune alternative à recommander, mais je peux fournir des suggestions pour accélérer sshfs:

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

Cela devrait éviter certaines des demandes d'aller-retour lorsque vous essayez de lire du contenu ou des autorisations pour des fichiers que vous avez déjà récupérés plus tôt dans votre session.

sshfs simule les suppressions et les modifications localement. Par conséquent, les nouvelles modifications effectuées sur la machine locale doivent apparaître immédiatement, malgré les délais importants, car les données en cache sont automatiquement supprimées.

Mais ces options ne sont pas recommandées si les fichiers distants peuvent être mis à jour sans que la machine locale ne le sache, par exemple par un autre utilisateur ou par un shell ssh distant. Dans ce cas, des délais plus courts seraient préférables.

Voici quelques autres options que j'ai expérimentées, bien que je ne sois pas sûr qu'elles fassent la différence:

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"

Vous devriez également vérifier les options recommandées par Meetai dans sa réponse.

Récursion

Le plus gros problème de mon flux de travail est lorsque j'essaie de lire plusieurs dossiers, par exemple dans une arborescence profonde, car sshfs effectue une demande d'aller-retour pour chaque dossier séparément. Cela peut également être le goulot d'étranglement que vous rencontrez avec Eclipse.

Effectuer des demandes pour plusieurs dossiers en parallèle peut aider, mais la plupart des applications ne le font pas: elles ont été conçues pour des systèmes de fichiers à faible latence avec mise en cache à lecture anticipée, de sorte qu'elles attendent la fin d'une statistique de fichier avant de passer à la suivante. .

Précaché

Mais quelque chose que sshfs pourrait faire serait de regarder en avant le système de fichiers distant, de collecter les statistiques de dossiers avant que je ne les demande, et de me les envoyer lorsque la connexion n’est pas immédiatement occupée. Cela utiliserait plus de bande passante (à partir de données inattendues jamais utilisées) mais pourrait améliorer la vitesse.

Nous pouvons forcer sshfs à faire de la mise en cache à lecture anticipée, en l'exécutant avant de commencer votre tâche, ou même en arrière-plan lorsque votre tâche est déjà en cours:

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

Cela devrait pré-mettre en cache toutes les entrées du répertoire, ce qui réduira certains des frais généraux liés aux allers-retours. (Bien entendu, vous devez utiliser les délais importants, comme ceux que j'ai fournis précédemment, sinon ces données en cache seront effacées avant que votre application n'y accède.)

Mais cela findprendra beaucoup de temps. Comme d'autres applications, il attend les résultats d'un dossier avant de demander le suivant.

Il serait peut-être possible de réduire le temps total en demandant à plusieurs processus de recherche de consulter différents dossiers. Je n'ai pas testé pour voir si cela est vraiment plus efficace. Cela dépend si sshfs autorise les requêtes en parallèle. (Je pense que c'est le cas.)

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 &

Si vous souhaitez également pré-mettre en cache le contenu des fichiers, vous pouvez essayer ceci:

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

Évidemment, cela prendra beaucoup plus de temps, transférera beaucoup de données et nécessitera une taille de cache énorme. Mais quand c'est fait, accéder aux fichiers devrait être agréable et rapide.

Joeytwiddle
la source
4

SSHFS est très lent car il transfère le contenu du fichier même s’il n’est pas obligé (lorsqu’on fait cp). J'ai signalé cela en amont et à Debian, mais aucune réponse: /

Daniel Milde
la source
2
C'est efficace avec mv. Malheureusement, lorsque vous exécutez en cplocal, FUSE ne voit que les demandes d'ouverture de fichiers en lecture et en écriture. Il ne sait pas que vous faites une copie d'un fichier. Pour FUSE, l’échange de fichiers n’est pas différent. Donc, je crains que cela ne puisse être corrigé à moins que la section locale cpsoit davantage sensibilisée à FUSE / à FUSE. (Ou FUSE pourrait peut-être envoyer des hachages de blocs au lieu de blocs entiers lorsqu'il soupçonne un cp, comme le fait rsync, mais cela serait complexe et pourrait ralentir d'autres opérations.)
joeytwiddle
3

Après la recherche et le procès. Je viens de trouver ajouter de la -o Compression=novitesse beaucoup. Le délai peut être dû au processus de compression et de décompression. Par ailleurs, utiliser 'Ciphers = aes128-ctr' semble plus rapide que d'autres alors que certains post ont fait des expériences à ce sujet. Ensuite, ma commande est en quelque sorte comme ceci:

sshfs -o allow_other, transform_symlinks, follow_symlinks, IdentityFile = / Utilisateurs / maple / .ssh / id_rsa -o auto_cache, reconnectez-vous, defer_permissions -o Ciphers = aes128-ctr -o Compression = no [email protected]: / home / maple ~ / mntpoint

érable
la source
2

NFS devrait être plus rapide. Quelle est la distance du système de fichiers? Si c'est le cas sur le réseau étendu, vous feriez peut-être mieux de synchroniser les fichiers, plutôt que d'accéder directement à distance.

Adam Wagner
la source
1

NFS ou Samba si vous avez des fichiers volumineux. Utiliser NFS avec quelque chose comme 720p Movies and Crap est vraiment un PITA. Samba fera un meilleur travail, même si je n'aime pas Samba pour un certain nombre d'autres raisons et je ne le recommanderais généralement pas.

NFS devrait convenir aux petits fichiers.

Franz Bettag
la source
1

J'ai trouvé que le fait d'éteindre mon thème zsh qui vérifiait l'état du fichier git m'aidait énormément - entrer dans le répertoire prenait plus de 10 minutes. De même, désactiver les vérificateurs d'état Git dans Vim.

bloke_zero
la source
Wow, c'est un très bon conseil!
Dimitri
-2

Connectez-vous en tant que root.

Accédez à votre répertoire de niveau supérieur en utilisant "cd /".

Ensuite, assurez-vous d'avoir créé un dossier de montage ou créez-en un en utilisant "mkdir folder_name".

Après cela, utilisez simplement "mount xxxx: / remote_mount_directory / local_mount_directory.

si tout a fonctionné de votre côté, auparavant, vous devriez avoir une monture réussie. Vous voudrez peut-être vérifier et vous assurer que le répertoire de destination est partagé en utilisant la commande "exportfs" pour vous assurer qu'ils peuvent être trouvés.

J'espère que cela t'aides. Ce n'est pas à partir d'un environnement lvie, il a été testé sur un réseau local utilisant VMware et Fedora 16.

JasonN
la source
5
Cela ne répond pas à la question…
Léo Lam