Empêcher la connection NFS brisée de geler le système client

Nous avons un partage NFS 4, partageant un volume entre un certain nombre de servers (server NFS et clients tous Debian 8). Nous avons eu quelques problèmes récemment où les pannes de réseau gèleraient les systèmes clients.

Nos options NFS étaient minimes, juste rw (et donc les valeurs par défaut hard , fg , etc).

J'expérimente maintenant ces options, mais je n'obtiens pas le comportement que j'attends: rw,soft,bg,retrans=6,timeo=150

(J'ai augmenté les retrans pour compenser une partie du risque doux)

La procédure que je suis en train de tester est la suivante:

  • Machine de démarrage
  • cd vers /mnt/mountpoint
  • Vérifier la connection NFS ok
  • cd /
  • tuer le réseau ifdown eth0
  • cd vers /mnt/mountpoint
  • ls

À ce stade, la command line se fige et je ne peux pas l'interrompre. Après un certain time, le message 'nfs: server [nomserver] ne répond pas, a expiré', qui semble répéter une fois par minute (indéfiniment).

Ce que j'aimerais / j'attends de l'échec de l'opération et du return du contrôle.

S'il vous plaît quelqu'un pourrait me dire où je vais mal avec ces parameters?

(PS: J'ai aussi essayé de monter avec autofs, mais j'ai vu un comportement similaire)

Je vous remercie

intr devrait vous permettre de reprendre le contrôle quand vous frappez ^C , mais généralement pas immédiatement.

  intr If an NFS file operation has a major timeout and it is hard mounted, then allow signals to interupt the file operation and cause it to return EINTR to the calling program. The default is to not allow file operations to be interrupted. 

Comme vous le dites, les attentes sont le problème ici. Les problèmes de réseau peuvent être temporaires, mais l'échec d'une opération est permanent. Ainsi, la plupart des opérations par défaut se bloquent simplement jusqu'à ce que l'opération soit terminée.

C'est la réponse standard, mais en regardant une page man actuelle, je vois ceci:

  The intr / nointr mount option is deprecated after ker- nel 2.6.25. Only SIGKILL can interrupt a pending NFS operation on these kernels, and if specified, this mount option is ignored to provide backwards compatibility with older kernels. 

Donc, il ne me semble pas être un problème NFS3 / NFS4, mais une décision sur le fonctionnement de l' intr . Vous devriez donc être en mesure de KILL le process, mais cela peut ne pas vous donner beaucoup d'utilité.

Je n'ai pas pu find la discussion sur la raison pour laquelle l'option a été supprimée. Pouvez-vous tuer -KILL votre process?

Une partie de ma réponse est l'opinion, basée sur l'expérience. Là où j'ai des faits, je vais (essayer de me callbacker de) lien avec eux.

  1. NFS 4 est considéré comme une amélioration par rapport aux versions 2 et 3. Cependant, je n'ai pas encore vu un cas d'utilisation fort pour avoir besoin des améliorations. C'est peut-être parce que je vise à exporter des filesystems vers des clients Windows avec Samba et vers des clients Unix / Linux avec NFS.
  2. Je ne reorderais pas soft dans presque toutes les circonstances. Il permet de rejeter des données en cas d'erreur . Au lieu de cela, je suggérerais hard,intr .
  3. Comme vous le intr , intr n'est pas valide pour NFS 4, mais il semble qu'il s'agisse d'un changement de kernel plutôt que d'un NFS.
  4. Le NFS autofs ( autofs ) fonctionne bien avec les versions 2 et 3 de NFS, et parvient à protéger mes systèmes clients contre les pannes de server en installant les filesystems NFS uniquement lorsqu'ils sont requirejs.

Ma suggestion pour vous serait de passer de NFS 4 à NFS 3 et de voir si cela vous aide dans votre cas d'utilisation particulier. Ne pensez pas qu'il s'agit d'un downgrade.