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

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.

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 .

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

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.

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.

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: /

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 maple@123.123.123.123: / home / maple ~ / mntpoint

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.

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.

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.

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.