SSHFS ne survit pas très bien à une coupure active longue de la connexion, c'est à dire si une des deux machines est active et l'autre en veille par exemple.
Je crois que si les deux sont en veille ça va revenir sans soucis en rallumant les deux.
Mais en bref, ça survit exactement aussi bien aux aléas de connexion qu'une connexion SSH classique. Puisque c'en est une en dessous.
En comparaison, NFS sur le client ne se déconnecte pas tout seul, et les processus qui cherchent à accéder à la ressource NFS inaccessible vont être mis en attente par le système, selon comment le logiciel est écrit, ça peut le freezer sans espoir de rédemption (kill -9 est inutile). Mais tout repart comme si de rien n'était dès que la connexion NFS revient. Et la connexion NFS se recrée toute seule dès que le serveur redevient accessible.
Il est possible (mais j'ai des résultats mitigés à ce sujet) de flinguer une connexion bloquée (connexion NFS active mais vers un serveur devenu indisponible) en tuant le démon RPC.
À comparer : si ta connexion SSHFS est dans les choux, tu as le processus SSH à tuer et ça coupe la connexion proprement, les logiciels qui essayaient d'accéder aux données reprennent leur cours normalement avec une erreur d'entrée/sortie normale.
Côté performance, même en réseau local je préfère utiliser le NFS, de loin, pour transférer des gros fichiers ou lire une vidéo depuis une autre machine : bien plus rapide.
Mais le NFS est à la limite de l'inutilisable sur internet (de mon expérience uniquement) alors que SSHFS s'en sort bien mieux, et est plus facile à gérer en cas de soucis de connexion.
Autre point notable, il n'y a rien à installer ou configurer sur le serveur pour faire fonctionner SSHFS, et aucun droits d'administration, juste un compte utilisateur. Il faut bien sûr avoir le serveur SSH actif, ce qui est facilement le cas. Tandis que pour le NFS il faut accéder au serveur en ROOT, configurer le fichier /etc/exports, relancer le démon NFS, blablabla...
Bref, pas les mêmes usages, et très complémentaires !
J'utilise fortement les deux dans un même environnement.
[^] # Re: Résilience
Posté par Yth (Mastodon) . En réponse au journal SSHFS est un vrai système de fichiers en réseau. Évalué à 6.
SSHFS ne survit pas très bien à une coupure active longue de la connexion, c'est à dire si une des deux machines est active et l'autre en veille par exemple.
Je crois que si les deux sont en veille ça va revenir sans soucis en rallumant les deux.
Mais en bref, ça survit exactement aussi bien aux aléas de connexion qu'une connexion SSH classique. Puisque c'en est une en dessous.
En comparaison, NFS sur le client ne se déconnecte pas tout seul, et les processus qui cherchent à accéder à la ressource NFS inaccessible vont être mis en attente par le système, selon comment le logiciel est écrit, ça peut le freezer sans espoir de rédemption (kill -9 est inutile). Mais tout repart comme si de rien n'était dès que la connexion NFS revient. Et la connexion NFS se recrée toute seule dès que le serveur redevient accessible.
Il est possible (mais j'ai des résultats mitigés à ce sujet) de flinguer une connexion bloquée (connexion NFS active mais vers un serveur devenu indisponible) en tuant le démon RPC.
À comparer : si ta connexion SSHFS est dans les choux, tu as le processus SSH à tuer et ça coupe la connexion proprement, les logiciels qui essayaient d'accéder aux données reprennent leur cours normalement avec une erreur d'entrée/sortie normale.
Côté performance, même en réseau local je préfère utiliser le NFS, de loin, pour transférer des gros fichiers ou lire une vidéo depuis une autre machine : bien plus rapide.
Mais le NFS est à la limite de l'inutilisable sur internet (de mon expérience uniquement) alors que SSHFS s'en sort bien mieux, et est plus facile à gérer en cas de soucis de connexion.
Autre point notable, il n'y a rien à installer ou configurer sur le serveur pour faire fonctionner SSHFS, et aucun droits d'administration, juste un compte utilisateur. Il faut bien sûr avoir le serveur SSH actif, ce qui est facilement le cas. Tandis que pour le NFS il faut accéder au serveur en ROOT, configurer le fichier /etc/exports, relancer le démon NFS, blablabla...
Bref, pas les mêmes usages, et très complémentaires !
J'utilise fortement les deux dans un même environnement.
Yth.