J'ai rencontré un amusant problème ce week-end : j'ai monté par NFS un
disque d'une machine sur une autre, très bien, pas de problème.
Bon, là où j'ai lousé, c'est que j'ai fait ça comme un goret avec des
histoires de mélanges de différents réseaux, et que bon, le résultat,
c'est que je montais le disque en lui donnant une addresse IP dynamique.
En fait, je faisais un 'mount toto.dyndns.org:/bla /bla', sans m'être
rendu compte qu'il résolvait toto.dyndns.org en son adresse IP réelle,
alors que, étant à l'intérieur d'un réseau perso, j'aurais dû me réferer à
cette machine par 10.0.quelque chose, mais pas comme ça.
Bref, j'ai merdouillé ça, et fatalement, ce qui devait arriver arriva :
l'adresse IP du serveur NFS a été modifiée, et du coup, mon montage NFS,
qui cherchait encore et toujours l'ancienne adresse IP, pédalait grave
dans la choucroute...
Du coup, tous les processus qui accédaient à ce montage plantaient
complétement. J'aurais donc voulu demonter ce disque, pour le remonter
plus proprement. Le problème, c'est qu'un umount sur ce disque plantait
aussi (enfin, tournait sans fin), et que je ne pouvais pas "surcharger" le
répértoire en refaisant un mount dessus. Le point de montage était donc
totalement inutilisable. Bien sûr, je pouvais remonter le "vrai" disque
par NFS sur un autre point de montage, mais pas sur le premier.
Comment aurais-je donc pu faire pour "tuer" ce mount mal barré, histoire
de récupérer le point de montage ? Je n'ai pas réussi à tuer le client
NFS (ou du moins les processus qui m'y semblaient liés), ni à lui faire
ignorer le mount précédent en modifiant /etc/mtab (ben oui, on sait jamais
?)...
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
-- Antoine Bellot : It's not an exact reference, due to the fact that the API changes from version to version, and that the kernel API is not required to match the documentation. -- Jamie Lokier abt LDD-3
Remi Moyen a écrit:
Salut,
J'ai rencontré un amusant problème ce week-end : j'ai monté par NFS un
disque d'une machine sur une autre, très bien, pas de problème.
Puisqu'apparemment, vous utilisez Linux, jetez un oeil à :
--
Antoine Bellot :
It's not an exact reference, due to the fact that the API changes
from version to version, and that the kernel API is not required
to match the documentation. -- Jamie Lokier abt LDD-3
-- Antoine Bellot : It's not an exact reference, due to the fact that the API changes from version to version, and that the kernel API is not required to match the documentation. -- Jamie Lokier abt LDD-3
Remi Moyen
On Mon, 2 Feb 2004, Antoine Bellot wrote:
J'ai rencontré un amusant problème ce week-end : j'ai monté par NFS un disque d'une machine sur une autre, très bien, pas de problème.
Puisqu'apparemment, vous utilisez Linux, jetez un oeil à :
Voui, c'est le cas. Quoique, postant d'une autre machine que celle sur laquelle j'ai eu le problème, ça n'était pas obligé...
Ah, oui, merci ! Ça semble effectivement être ce qui m'est arrivé. Je vais rapidement rajouter ces options lors du montage.
À vue d'oeil, il semble plus intéressant de mettre hard et intr, que de mettre soft, puisque soft nécessite de préciser un time-out. L'intérêt du soft semble alors uniquement être qu'il "marche" toujours, contrairement à ce que l'url citée indique pour intr. Ai-je bien compris ?
Et si oui, est-ce que les cas où le intr ne marche pas sont fréquents ?
Pis d'abord, j'avais essayé de tuer les process et le rpc, mais ça marchait pô... J'avais du oublier de tuer certains process, je pense... -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
On Mon, 2 Feb 2004, Antoine Bellot wrote:
J'ai rencontré un amusant problème ce week-end : j'ai monté par NFS un
disque d'une machine sur une autre, très bien, pas de problème.
Puisqu'apparemment, vous utilisez Linux, jetez un oeil à :
Voui, c'est le cas. Quoique, postant d'une autre machine que celle sur
laquelle j'ai eu le problème, ça n'était pas obligé...
Ah, oui, merci ! Ça semble effectivement être ce qui m'est arrivé. Je vais
rapidement rajouter ces options lors du montage.
À vue d'oeil, il semble plus intéressant de mettre hard et intr, que de
mettre soft, puisque soft nécessite de préciser un time-out. L'intérêt du
soft semble alors uniquement être qu'il "marche" toujours, contrairement à
ce que l'url citée indique pour intr. Ai-je bien compris ?
Et si oui, est-ce que les cas où le intr ne marche pas sont fréquents ?
Pis d'abord, j'avais essayé de tuer les process et le rpc, mais ça
marchait pô... J'avais du oublier de tuer certains process, je pense...
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
Ah, oui, merci ! Ça semble effectivement être ce qui m'est arrivé. Je vais rapidement rajouter ces options lors du montage.
À vue d'oeil, il semble plus intéressant de mettre hard et intr, que de mettre soft, puisque soft nécessite de préciser un time-out. L'intérêt du soft semble alors uniquement être qu'il "marche" toujours, contrairement à ce que l'url citée indique pour intr. Ai-je bien compris ?
Et si oui, est-ce que les cas où le intr ne marche pas sont fréquents ?
Pis d'abord, j'avais essayé de tuer les process et le rpc, mais ça marchait pô... J'avais du oublier de tuer certains process, je pense... -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
Antoine Bellot
Remi Moyen a écrit:
À vue d'oeil, il semble plus intéressant de mettre hard et intr, que de mettre soft, puisque soft nécessite de préciser un time-out. L'intérêt du soft semble alors uniquement être qu'il "marche" toujours, contrairement à ce que l'url citée indique pour intr. Ai-je bien compris ?
Et si oui, est-ce que les cas où le intr ne marche pas sont fréquents ?
D'un point de vue strictement pragmatique, et dans le cadre d'une exploitation classique (donc, excluant les stations diskless, le swap sur NFS, et l'usage de logiciels de conception antédéluvienne ou particulièrement innovants), le facteur-clé à évaluer est la probabilité qu'a le serveur NFS de se casser la gueule pendant un temps relativement long à un instant auquel vous ne souhaitez pas devoir intervenir manuellement sur l'un ou l'autre de ses clients.
Remi Moyen a écrit:
À vue d'oeil, il semble plus intéressant de mettre hard et intr, que de
mettre soft, puisque soft nécessite de préciser un time-out. L'intérêt du
soft semble alors uniquement être qu'il "marche" toujours, contrairement à
ce que l'url citée indique pour intr. Ai-je bien compris ?
Et si oui, est-ce que les cas où le intr ne marche pas sont fréquents ?
D'un point de vue strictement pragmatique, et dans le cadre d'une
exploitation classique (donc, excluant les stations diskless, le swap
sur NFS, et l'usage de logiciels de conception antédéluvienne ou
particulièrement innovants), le facteur-clé à évaluer est la probabilité
qu'a le serveur NFS de se casser la gueule pendant un temps relativement
long à un instant auquel vous ne souhaitez pas devoir intervenir
manuellement sur l'un ou l'autre de ses clients.
À vue d'oeil, il semble plus intéressant de mettre hard et intr, que de mettre soft, puisque soft nécessite de préciser un time-out. L'intérêt du soft semble alors uniquement être qu'il "marche" toujours, contrairement à ce que l'url citée indique pour intr. Ai-je bien compris ?
Et si oui, est-ce que les cas où le intr ne marche pas sont fréquents ?
D'un point de vue strictement pragmatique, et dans le cadre d'une exploitation classique (donc, excluant les stations diskless, le swap sur NFS, et l'usage de logiciels de conception antédéluvienne ou particulièrement innovants), le facteur-clé à évaluer est la probabilité qu'a le serveur NFS de se casser la gueule pendant un temps relativement long à un instant auquel vous ne souhaitez pas devoir intervenir manuellement sur l'un ou l'autre de ses clients.
