Soit un serveur sous Debian avec un noyau 3.2.50 "vanilla" (aucun patch)
qui exporte /partage en NFS.
Soit une VM sous ESX sous Ubuntu 12.04LTS avec un 3.2.0-32, qui monte
serveur:/partage sur /serveur.
Sur la VM, si je fais
find /serveur/dossier1/dossier2 -type f -exec stat {} \; > /tmp/LISTE
L'accès à NFS tombe en panne. On peut toujours pinger le serveur depuis
la VM, faire un wget http://serveur, etc, mais plus de NFS. Il faut
rebooter la VM. Aucun message d'erreur nulle part, ni sur le serveur ni
sur le client (rien dans dmesg, /var/log/messages, /var/log/syslog).
Redémarrer le service nfs-kernel-server sur le serveur ne fait rien,
donc c'est bien côté client que ça merde. Booter le serveur sur un noyau
complètement différent (3.9.7) ne fait aucun différence.
Si on reboote la VM et qu'on recommence, ça bloque, et TOUJOURS SUR LE
MÊME FICHIER, /serveur/dossier1/dossier2/dossier3/.dossier4/fichier .
Si on fait 'stat /serveur/dossier1/dossier2/dossier3/.dossier4/fichier'
ça marche très bien. Si on fait
cd /serveur/dossier1/dossier2/dossier3 && find . -type f -exec stat {} \;
ça marche aussi... Mais si on fait
cd /serveur/dossier1/dossier2 && find . -type f -exec stat {} \;
ça plante, et encore une fois TOUJOURS SUR LE MÊME FICHIER. Dans le
premier test ça plante après avoir fait "stat" sur plus de 10000
fichiers, mais dans le dernier test ça plante au 25e fichier.
J'ai aussi essayé en nfs4. Pareil (pourtant le protocole est sensiblement
différent, il me semble).
C'est à devenir fou. Je vais faire un tcpdump et analyser tout ça, mais
j'y perd vraiment mon latin. Est-ce que quelqu'un a une idée? Pitié,
dites que oui :)
--
Je suis riche des biens dont je sais me passer.
Louis-Jean-Baptiste Etienne Vigée.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
wr35nn89
Le 04/09/2013 23:25, Emmanuel Florac a écrit :
Soit un serveur sous Debian avec un noyau 3.2.50 "vanilla" (aucun patch) qui exporte /partage en NFS.
Soit une VM sous ESX sous Ubuntu 12.04LTS avec un 3.2.0-32, qui monte serveur:/partage sur /serveur.
Sur la VM, si je fais
find /serveur/dossier1/dossier2 -type f -exec stat {} ; > /tmp/LISTE
L'accès à NFS tombe en panne. On peut toujours pinger le serveur depuis la VM, faire un wget http://serveur, etc, mais plus de NFS. Il faut rebooter la VM. Aucun message d'erreur nulle part, ni sur le serveur ni sur le client (rien dans dmesg, /var/log/messages, /var/log/syslog). Redémarrer le service nfs-kernel-server sur le serveur ne fait rien, donc c'est bien côté client que ça merde. Booter le serveur sur un noyau complètement différent (3.9.7) ne fait aucun différence.
Si on reboote la VM et qu'on recommence, ça bloque, et TOUJOURS SUR LE MÊME FICHIER, /serveur/dossier1/dossier2/dossier3/.dossier4/fichier .
Si on fait 'stat /serveur/dossier1/dossier2/dossier3/.dossier4/fichier' ça marche très bien. Si on fait
cd /serveur/dossier1/dossier2/dossier3 && find . -type f -exec stat {} ;
ça marche aussi... Mais si on fait
cd /serveur/dossier1/dossier2 && find . -type f -exec stat {} ;
ça plante, et encore une fois TOUJOURS SUR LE MÊME FICHIER. Dans le premier test ça plante après avoir fait "stat" sur plus de 10000 fichiers, mais dans le dernier test ça plante au 25e fichier.
J'ai aussi essayé en nfs4. Pareil (pourtant le protocole est sensiblement différent, il me semble).
C'est à devenir fou. Je vais faire un tcpdump et analyser tout ça, mais j'y perd vraiment mon latin. Est-ce que quelqu'un a une idée? Pitié, dites que oui :)
Hello, j'ai eu de gros soucis avec un serveur NFS avec un noyau à peu près identique (je ne me souviens plus de la version, désolé...). Mais les symptômes étaient identiques : le poste de travail figeait et je n'avais plus qu'à l'éteindre. Et évidemment, rien dans les logs..... En cause, NFS buggué au niveau du noyau. Essaie de mettre un kernel plus récent sur ton client.....
-- A bove majore discit arare minor
Le 04/09/2013 23:25, Emmanuel Florac a écrit :
Soit un serveur sous Debian avec un noyau 3.2.50 "vanilla" (aucun patch)
qui exporte /partage en NFS.
Soit une VM sous ESX sous Ubuntu 12.04LTS avec un 3.2.0-32, qui monte
serveur:/partage sur /serveur.
Sur la VM, si je fais
find /serveur/dossier1/dossier2 -type f -exec stat {} ; > /tmp/LISTE
L'accès à NFS tombe en panne. On peut toujours pinger le serveur depuis
la VM, faire un wget http://serveur, etc, mais plus de NFS. Il faut
rebooter la VM. Aucun message d'erreur nulle part, ni sur le serveur ni
sur le client (rien dans dmesg, /var/log/messages, /var/log/syslog).
Redémarrer le service nfs-kernel-server sur le serveur ne fait rien,
donc c'est bien côté client que ça merde. Booter le serveur sur un noyau
complètement différent (3.9.7) ne fait aucun différence.
Si on reboote la VM et qu'on recommence, ça bloque, et TOUJOURS SUR LE
MÊME FICHIER, /serveur/dossier1/dossier2/dossier3/.dossier4/fichier .
Si on fait 'stat /serveur/dossier1/dossier2/dossier3/.dossier4/fichier'
ça marche très bien. Si on fait
cd /serveur/dossier1/dossier2/dossier3 && find . -type f -exec stat {} ;
ça marche aussi... Mais si on fait
cd /serveur/dossier1/dossier2 && find . -type f -exec stat {} ;
ça plante, et encore une fois TOUJOURS SUR LE MÊME FICHIER. Dans le
premier test ça plante après avoir fait "stat" sur plus de 10000
fichiers, mais dans le dernier test ça plante au 25e fichier.
J'ai aussi essayé en nfs4. Pareil (pourtant le protocole est sensiblement
différent, il me semble).
C'est à devenir fou. Je vais faire un tcpdump et analyser tout ça, mais
j'y perd vraiment mon latin. Est-ce que quelqu'un a une idée? Pitié,
dites que oui :)
Hello,
j'ai eu de gros soucis avec un serveur NFS avec un noyau à peu près
identique (je ne me souviens plus de la version, désolé...). Mais les
symptômes étaient identiques : le poste de travail figeait et je n'avais
plus qu'à l'éteindre. Et évidemment, rien dans les logs.....
En cause, NFS buggué au niveau du noyau. Essaie de mettre un kernel plus
récent sur ton client.....
Soit un serveur sous Debian avec un noyau 3.2.50 "vanilla" (aucun patch) qui exporte /partage en NFS.
Soit une VM sous ESX sous Ubuntu 12.04LTS avec un 3.2.0-32, qui monte serveur:/partage sur /serveur.
Sur la VM, si je fais
find /serveur/dossier1/dossier2 -type f -exec stat {} ; > /tmp/LISTE
L'accès à NFS tombe en panne. On peut toujours pinger le serveur depuis la VM, faire un wget http://serveur, etc, mais plus de NFS. Il faut rebooter la VM. Aucun message d'erreur nulle part, ni sur le serveur ni sur le client (rien dans dmesg, /var/log/messages, /var/log/syslog). Redémarrer le service nfs-kernel-server sur le serveur ne fait rien, donc c'est bien côté client que ça merde. Booter le serveur sur un noyau complètement différent (3.9.7) ne fait aucun différence.
Si on reboote la VM et qu'on recommence, ça bloque, et TOUJOURS SUR LE MÊME FICHIER, /serveur/dossier1/dossier2/dossier3/.dossier4/fichier .
Si on fait 'stat /serveur/dossier1/dossier2/dossier3/.dossier4/fichier' ça marche très bien. Si on fait
cd /serveur/dossier1/dossier2/dossier3 && find . -type f -exec stat {} ;
ça marche aussi... Mais si on fait
cd /serveur/dossier1/dossier2 && find . -type f -exec stat {} ;
ça plante, et encore une fois TOUJOURS SUR LE MÊME FICHIER. Dans le premier test ça plante après avoir fait "stat" sur plus de 10000 fichiers, mais dans le dernier test ça plante au 25e fichier.
J'ai aussi essayé en nfs4. Pareil (pourtant le protocole est sensiblement différent, il me semble).
C'est à devenir fou. Je vais faire un tcpdump et analyser tout ça, mais j'y perd vraiment mon latin. Est-ce que quelqu'un a une idée? Pitié, dites que oui :)
Hello, j'ai eu de gros soucis avec un serveur NFS avec un noyau à peu près identique (je ne me souviens plus de la version, désolé...). Mais les symptômes étaient identiques : le poste de travail figeait et je n'avais plus qu'à l'éteindre. Et évidemment, rien dans les logs..... En cause, NFS buggué au niveau du noyau. Essaie de mettre un kernel plus récent sur ton client.....
-- A bove majore discit arare minor
wr35nn89
Le 04/09/2013 23:25, Emmanuel Florac a écrit :
Soit un serveur sous Debian avec un noyau 3.2.50 "vanilla" (aucun patch) qui exporte /partage en NFS.
Soit une VM sous ESX sous Ubuntu 12.04LTS avec un 3.2.0-32, qui monte serveur:/partage sur /serveur.
Sur la VM, si je fais
find /serveur/dossier1/dossier2 -type f -exec stat {} ; > /tmp/LISTE
L'accès à NFS tombe en panne. On peut toujours pinger le serveur depuis la VM, faire un wget http://serveur, etc, mais plus de NFS. Il faut rebooter la VM. Aucun message d'erreur nulle part, ni sur le serveur ni sur le client (rien dans dmesg, /var/log/messages, /var/log/syslog). Redémarrer le service nfs-kernel-server sur le serveur ne fait rien, donc c'est bien côté client que ça merde. Booter le serveur sur un noyau complètement différent (3.9.7) ne fait aucun différence.
Si on reboote la VM et qu'on recommence, ça bloque, et TOUJOURS SUR LE MÊME FICHIER, /serveur/dossier1/dossier2/dossier3/.dossier4/fichier .
Si on fait 'stat /serveur/dossier1/dossier2/dossier3/.dossier4/fichier' ça marche très bien. Si on fait
cd /serveur/dossier1/dossier2/dossier3 && find . -type f -exec stat {} ;
ça marche aussi... Mais si on fait
cd /serveur/dossier1/dossier2 && find . -type f -exec stat {} ;
ça plante, et encore une fois TOUJOURS SUR LE MÊME FICHIER. Dans le premier test ça plante après avoir fait "stat" sur plus de 10000 fichiers, mais dans le dernier test ça plante au 25e fichier.
J'ai aussi essayé en nfs4. Pareil (pourtant le protocole est sensiblement différent, il me semble).
C'est à devenir fou. Je vais faire un tcpdump et analyser tout ça, mais j'y perd vraiment mon latin. Est-ce que quelqu'un a une idée? Pitié, dites que oui :)
Hello, j'ai eu de gros soucis avec un serveur NFS avec un noyau à peu près identique (je ne me souviens plus de la version, désolé...). Mais les symptômes étaient identiques : le poste de travail figeait et je n'avais plus qu'à l'éteindre. Et évidemment, rien dans les logs..... En cause, NFS buggué au niveau du noyau. Essaie de mettre un kernel plus récent sur ton client.....
-- A bove majore discit arare minor
Le 04/09/2013 23:25, Emmanuel Florac a écrit :
Soit un serveur sous Debian avec un noyau 3.2.50 "vanilla" (aucun patch)
qui exporte /partage en NFS.
Soit une VM sous ESX sous Ubuntu 12.04LTS avec un 3.2.0-32, qui monte
serveur:/partage sur /serveur.
Sur la VM, si je fais
find /serveur/dossier1/dossier2 -type f -exec stat {} ; > /tmp/LISTE
L'accès à NFS tombe en panne. On peut toujours pinger le serveur depuis
la VM, faire un wget http://serveur, etc, mais plus de NFS. Il faut
rebooter la VM. Aucun message d'erreur nulle part, ni sur le serveur ni
sur le client (rien dans dmesg, /var/log/messages, /var/log/syslog).
Redémarrer le service nfs-kernel-server sur le serveur ne fait rien,
donc c'est bien côté client que ça merde. Booter le serveur sur un noyau
complètement différent (3.9.7) ne fait aucun différence.
Si on reboote la VM et qu'on recommence, ça bloque, et TOUJOURS SUR LE
MÊME FICHIER, /serveur/dossier1/dossier2/dossier3/.dossier4/fichier .
Si on fait 'stat /serveur/dossier1/dossier2/dossier3/.dossier4/fichier'
ça marche très bien. Si on fait
cd /serveur/dossier1/dossier2/dossier3 && find . -type f -exec stat {} ;
ça marche aussi... Mais si on fait
cd /serveur/dossier1/dossier2 && find . -type f -exec stat {} ;
ça plante, et encore une fois TOUJOURS SUR LE MÊME FICHIER. Dans le
premier test ça plante après avoir fait "stat" sur plus de 10000
fichiers, mais dans le dernier test ça plante au 25e fichier.
J'ai aussi essayé en nfs4. Pareil (pourtant le protocole est sensiblement
différent, il me semble).
C'est à devenir fou. Je vais faire un tcpdump et analyser tout ça, mais
j'y perd vraiment mon latin. Est-ce que quelqu'un a une idée? Pitié,
dites que oui :)
Hello,
j'ai eu de gros soucis avec un serveur NFS avec un noyau à peu près
identique (je ne me souviens plus de la version, désolé...). Mais les
symptômes étaient identiques : le poste de travail figeait et je n'avais
plus qu'à l'éteindre. Et évidemment, rien dans les logs.....
En cause, NFS buggué au niveau du noyau. Essaie de mettre un kernel plus
récent sur ton client.....
Soit un serveur sous Debian avec un noyau 3.2.50 "vanilla" (aucun patch) qui exporte /partage en NFS.
Soit une VM sous ESX sous Ubuntu 12.04LTS avec un 3.2.0-32, qui monte serveur:/partage sur /serveur.
Sur la VM, si je fais
find /serveur/dossier1/dossier2 -type f -exec stat {} ; > /tmp/LISTE
L'accès à NFS tombe en panne. On peut toujours pinger le serveur depuis la VM, faire un wget http://serveur, etc, mais plus de NFS. Il faut rebooter la VM. Aucun message d'erreur nulle part, ni sur le serveur ni sur le client (rien dans dmesg, /var/log/messages, /var/log/syslog). Redémarrer le service nfs-kernel-server sur le serveur ne fait rien, donc c'est bien côté client que ça merde. Booter le serveur sur un noyau complètement différent (3.9.7) ne fait aucun différence.
Si on reboote la VM et qu'on recommence, ça bloque, et TOUJOURS SUR LE MÊME FICHIER, /serveur/dossier1/dossier2/dossier3/.dossier4/fichier .
Si on fait 'stat /serveur/dossier1/dossier2/dossier3/.dossier4/fichier' ça marche très bien. Si on fait
cd /serveur/dossier1/dossier2/dossier3 && find . -type f -exec stat {} ;
ça marche aussi... Mais si on fait
cd /serveur/dossier1/dossier2 && find . -type f -exec stat {} ;
ça plante, et encore une fois TOUJOURS SUR LE MÊME FICHIER. Dans le premier test ça plante après avoir fait "stat" sur plus de 10000 fichiers, mais dans le dernier test ça plante au 25e fichier.
J'ai aussi essayé en nfs4. Pareil (pourtant le protocole est sensiblement différent, il me semble).
C'est à devenir fou. Je vais faire un tcpdump et analyser tout ça, mais j'y perd vraiment mon latin. Est-ce que quelqu'un a une idée? Pitié, dites que oui :)
Hello, j'ai eu de gros soucis avec un serveur NFS avec un noyau à peu près identique (je ne me souviens plus de la version, désolé...). Mais les symptômes étaient identiques : le poste de travail figeait et je n'avais plus qu'à l'éteindre. Et évidemment, rien dans les logs..... En cause, NFS buggué au niveau du noyau. Essaie de mettre un kernel plus récent sur ton client.....
-- A bove majore discit arare minor
Emmanuel Florac
Le Thu, 05 Sep 2013 07:35:19 +0200, wr35nn89 a écrit:
En cause, NFS buggué au niveau du noyau. Essaie de mettre un kernel plus récent sur ton client.....
Je vais essayer de mettre le dernier, 3.2.0-52 pour voir si ça fait une différence.
-- L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas en avant. Kaid Ahmed.
Le Thu, 05 Sep 2013 07:35:19 +0200, wr35nn89 a écrit:
En cause, NFS
buggué au niveau du noyau. Essaie de mettre un kernel plus récent sur
ton client.....
Je vais essayer de mettre le dernier, 3.2.0-52 pour voir si ça fait une
différence.
--
L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas
en avant.
Kaid Ahmed.
Le Thu, 05 Sep 2013 07:56:36 +0000, Emmanuel Florac a écrit:
Je vais essayer de mettre le dernier, 3.2.0-52 pour voir si ça fait une différence.
Et non, hélas, le problème demeure à l'identique. Pas d'autre idée?
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
Francois Lafont
Bonsoir,
Le 05/09/2013 18:42, Emmanuel Florac a écrit :
Et non, hélas, le problème demeure à l'identique. Pas d'autre idée?
J'ai peur de ne pas pouvoir être d'une grande aide, mais bon je tente quand même une idée à 2 balles. Tu indiques que ton find plante toujours sur le même fichier. Mais si tu supprimes ce fameux fichier, est-ce tout fonctionne parfaitement ? Si oui, alors c'est peut-être le fichier en question qui a quelque chose de spécifique, voire qui est corrompu ou je ne sais quoi ?
-- François Lafont
Bonsoir,
Le 05/09/2013 18:42, Emmanuel Florac a écrit :
Et non, hélas, le problème demeure à l'identique. Pas d'autre idée?
J'ai peur de ne pas pouvoir être d'une grande aide, mais bon je tente
quand même une idée à 2 balles. Tu indiques que ton find plante
toujours sur le même fichier. Mais si tu supprimes ce fameux fichier,
est-ce tout fonctionne parfaitement ? Si oui, alors c'est peut-être
le fichier en question qui a quelque chose de spécifique, voire qui
est corrompu ou je ne sais quoi ?
Et non, hélas, le problème demeure à l'identique. Pas d'autre idée?
J'ai peur de ne pas pouvoir être d'une grande aide, mais bon je tente quand même une idée à 2 balles. Tu indiques que ton find plante toujours sur le même fichier. Mais si tu supprimes ce fameux fichier, est-ce tout fonctionne parfaitement ? Si oui, alors c'est peut-être le fichier en question qui a quelque chose de spécifique, voire qui est corrompu ou je ne sais quoi ?
-- François Lafont
Emmanuel Florac
Le Fri, 06 Sep 2013 00:37:06 +0200, Francois Lafont a écrit:
J'ai peur de ne pas pouvoir être d'une grande aide, mais bon je tente quand même une idée à 2 balles. Tu indiques que ton find plante toujours sur le même fichier. Mais si tu supprimes ce fameux fichier, est-ce tout fonctionne parfaitement ? Si oui, alors c'est peut-être le fichier en question qui a quelque chose de spécifique, voire qui est corrompu ou je ne sais quoi ?
Jusque là je n'ai pas supprimé le fichier, vu que c'est un système qui n'est pas à moi... Cependant le fichier est OK; on peut le lire sans problème. C'est seulement quand on lit les propriétés d'un certains nombre de fichiers que ça foire... En le supprimant je suppose que ça se mettrait juste à bugger sur un fichier différent.
-- Never ascribe to malice that which is adequately explained by incompetence. Hanlon's Razor.
Le Fri, 06 Sep 2013 00:37:06 +0200, Francois Lafont a écrit:
J'ai peur de ne pas pouvoir être d'une grande aide, mais bon je tente
quand même une idée à 2 balles. Tu indiques que ton find plante toujours
sur le même fichier. Mais si tu supprimes ce fameux fichier, est-ce tout
fonctionne parfaitement ? Si oui, alors c'est peut-être le fichier en
question qui a quelque chose de spécifique, voire qui est corrompu ou je
ne sais quoi ?
Jusque là je n'ai pas supprimé le fichier, vu que c'est un système qui
n'est pas à moi... Cependant le fichier est OK; on peut le lire sans
problème. C'est seulement quand on lit les propriétés d'un certains
nombre de fichiers que ça foire...
En le supprimant je suppose que ça se mettrait juste à bugger sur un
fichier différent.
--
Never ascribe to malice that which is adequately explained by
incompetence.
Hanlon's Razor.
Le Fri, 06 Sep 2013 00:37:06 +0200, Francois Lafont a écrit:
J'ai peur de ne pas pouvoir être d'une grande aide, mais bon je tente quand même une idée à 2 balles. Tu indiques que ton find plante toujours sur le même fichier. Mais si tu supprimes ce fameux fichier, est-ce tout fonctionne parfaitement ? Si oui, alors c'est peut-être le fichier en question qui a quelque chose de spécifique, voire qui est corrompu ou je ne sais quoi ?
Jusque là je n'ai pas supprimé le fichier, vu que c'est un système qui n'est pas à moi... Cependant le fichier est OK; on peut le lire sans problème. C'est seulement quand on lit les propriétés d'un certains nombre de fichiers que ça foire... En le supprimant je suppose que ça se mettrait juste à bugger sur un fichier différent.
-- Never ascribe to malice that which is adequately explained by incompetence. Hanlon's Razor.
Damien Wyart
* Emmanuel Florac in fr.comp.os.linux.configuration:
C'est à devenir fou. Je vais faire un tcpdump et analyser tout ça, mais j'y perd vraiment mon latin. Est-ce que quelqu'un a une idée? Pitié, dites que oui :)
TCP ou UDP ?
J'ai juste trouvé ça mais ça ne va pas t'aider beaucoup :
Pour le premier lien, pas de solution ; pour le second, ça cite un noyau Suse patché, mais impossible de trouver des détails sur le patch. Si c'est ce problème, il semble spécifique à un montage au dessus de TCP.
Sinon, ça pourrait être intéressant de tester sur le client avec une distrib "live" récente, pour voir si le problème est présent avec un noyau vraiment récent. Ou alors tenter un noyau Ubuntu d'une distrib suivante mais ça peut casser d'autres choses...
Est-ce que l'analyse des traces donne quelque chose ?
Sinon, tu peux toujours contacter la liste linux-nfs, il devraient pouvoir aider dans l'analyse du problème.
-- DW
* Emmanuel Florac <eflorac@imaginet.fr> in fr.comp.os.linux.configuration:
C'est à devenir fou. Je vais faire un tcpdump et analyser tout ça,
mais j'y perd vraiment mon latin. Est-ce que quelqu'un a une idée?
Pitié, dites que oui :)
TCP ou UDP ?
J'ai juste trouvé ça mais ça ne va pas t'aider beaucoup :
Pour le premier lien, pas de solution ; pour le second, ça cite un noyau
Suse patché, mais impossible de trouver des détails sur le patch. Si
c'est ce problème, il semble spécifique à un montage au dessus de TCP.
Sinon, ça pourrait être intéressant de tester sur le client avec une
distrib "live" récente, pour voir si le problème est présent avec un
noyau vraiment récent. Ou alors tenter un noyau Ubuntu d'une distrib
suivante mais ça peut casser d'autres choses...
Est-ce que l'analyse des traces donne quelque chose ?
Sinon, tu peux toujours contacter la liste linux-nfs, il devraient
pouvoir aider dans l'analyse du problème.
* Emmanuel Florac in fr.comp.os.linux.configuration:
C'est à devenir fou. Je vais faire un tcpdump et analyser tout ça, mais j'y perd vraiment mon latin. Est-ce que quelqu'un a une idée? Pitié, dites que oui :)
TCP ou UDP ?
J'ai juste trouvé ça mais ça ne va pas t'aider beaucoup :
Pour le premier lien, pas de solution ; pour le second, ça cite un noyau Suse patché, mais impossible de trouver des détails sur le patch. Si c'est ce problème, il semble spécifique à un montage au dessus de TCP.
Sinon, ça pourrait être intéressant de tester sur le client avec une distrib "live" récente, pour voir si le problème est présent avec un noyau vraiment récent. Ou alors tenter un noyau Ubuntu d'une distrib suivante mais ça peut casser d'autres choses...
Est-ce que l'analyse des traces donne quelque chose ?
Sinon, tu peux toujours contacter la liste linux-nfs, il devraient pouvoir aider dans l'analyse du problème.
-- DW
Emmanuel Florac
Le Fri, 06 Sep 2013 10:44:07 +0200, Damien Wyart a écrit:
Est-ce que l'analyse des traces donne quelque chose ?
Sinon, tu peux toujours contacter la liste linux-nfs, il devraient pouvoir aider dans l'analyse du problème.
Oui, j'ai posté aussi sur linux-nfs, il faut une trace réseau pour avancer, comme c'est un site client distant j'ai demandé s'il était possible d'essayer depuis une VM avec un noyau complètement différent (une Debian, une Suse, n'importe quoi sauf une Ubuntu), ou un serveur physique mais je n'ai pas eu de réponse. Du coup en attendant je vais faire un tcpdump et voir ce que ça donne...
-- The bearing of a child takes 9 months, no matter how many women are assigned. Fred Brooks
Le Fri, 06 Sep 2013 10:44:07 +0200, Damien Wyart a écrit:
Est-ce que l'analyse des traces donne quelque chose ?
Sinon, tu peux toujours contacter la liste linux-nfs, il devraient
pouvoir aider dans l'analyse du problème.
Oui, j'ai posté aussi sur linux-nfs, il faut une trace réseau pour
avancer, comme c'est un site client distant j'ai demandé s'il était
possible d'essayer depuis une VM avec un noyau complètement différent
(une Debian, une Suse, n'importe quoi sauf une Ubuntu), ou un serveur
physique mais je n'ai pas eu de réponse. Du coup en attendant je vais
faire un tcpdump et voir ce que ça donne...
--
The bearing of a child takes 9 months, no matter how many women are
assigned.
Fred Brooks
Le Fri, 06 Sep 2013 10:44:07 +0200, Damien Wyart a écrit:
Est-ce que l'analyse des traces donne quelque chose ?
Sinon, tu peux toujours contacter la liste linux-nfs, il devraient pouvoir aider dans l'analyse du problème.
Oui, j'ai posté aussi sur linux-nfs, il faut une trace réseau pour avancer, comme c'est un site client distant j'ai demandé s'il était possible d'essayer depuis une VM avec un noyau complètement différent (une Debian, une Suse, n'importe quoi sauf une Ubuntu), ou un serveur physique mais je n'ai pas eu de réponse. Du coup en attendant je vais faire un tcpdump et voir ce que ça donne...
-- The bearing of a child takes 9 months, no matter how many women are assigned. Fred Brooks
