Netzwerkverbindung bricht bei NFS Schreibzugriffen ab

[schuettert]

Hallo zusammen,

ich habe folgendes Problem: Wenn ich auf meinen NFS Server Daten schreiben lasse bricht nach einiger Zeit die Netzwerkverbindung ab. Laut ifconfig sind alle Interface aber noch up und ich kann auch vom Server aus die eigene IP anpingen allerdings nur die eigene. Von allen anderen Rechnern im Netz kann ich den Server nicht mehr anpingen. Nachdem ich das Netzwerk restartet habe läuft wieder alles bis zum nächsten schreibzugriff auf die NFS Freigaben. An der Hardware kann es eigendlich nicht liegen, da ich mit ftp beliebig große Datein auf den Rechner schieben kann. Ich habe schon alle möglichen und unmöglichen logfiles durchforstet aber leider keinen Eintrag gefunden der auf das Problem hinweist.

Ich habe auch schon verschiedene Kernel ausprobiert, leider ohne erfolg.

Meine Konfiguration:
Server: Debian 3 unstable, Kernel 2.6.6, nfs-kernel-server
Cleint: Windows (diverse NFS clients), verschiedene Linuxrechner unter anderen Debian und knoppix

Hat vieleicht jemand eine Idee wo das Problem liegt, wo ich eventuelle Debugausgaben herbekomme oder sogar wie ich das Problem lösen kann?

Mit Dank im voraus

[storm]

Tach,

hast du dir mal die Statistiken deiner Netzwerk-Interfaces nach so einem Abbruch angesehen? Sind da viel collisions oder dropped packets? Bzw. benutz mal nach
so einem Abbruch <nfsstat> und schau dir die Ausgabe mal genauer an.
Als Ursache käme dann die Netzwerkqualität in Frage,
vgl.: http://nfs.sourceforge.net/nfs-howto/pe ... EGOTIATION

Ansonsten sei dir nur http://nfs.sourceforge.net/nfs-howto/tr ... oting.html empfohlen.

ciao, frank

[schuettert]

Danke erst mal,

ich habe alle Systemausgaben (ifconfig, netstat, nfsstat) nochmals genau betrachtet konnte aber keinerlei Probleme feststellen (keine Collisions, rx error oder tx errors) auserdem habe ich mit den mii-tools die Netzwerkkarte fest auf 100MBit full duplex festgesetzt. Ich habe auch ein wenig mit den mountparamenter von nfs rumgespielt. Wenn ich die wsize und die rsize auf 4096 runtersetze kann ich bis knapp über 2GB schreiben aber dann habe ich wieder das selbe Problem. Noch kleiner kann ich die [r,w]size leider nicht setzen da sonst der livestream der gespeichert werden soll abbricht (DVB Stream von ca. 2-6 MBit/s). An der Festplatte kann es eigentlich nicht liegen die schafft so ca 15 MB/s (getestet mit hdparm). Außerdem kann ich parallel zur Streamaufzeichnung noch eine ftp session mit voller Bandbreite benutzen. Wobei volle Bandbreite bei dem Rechner (Panasonic Laptop mit 133MHz Pentium) leider nur ca. 900 kB/s netto bei ftp bedeutet. Die Prozessorauslastung bei reinem NFS streamen liegt bei unter 10 % und wie gesagt ich kann auch zeitgleich noch ftp transfers starten (allerdings ist dann die Prozessorauslastung bei über 90%). Um eventuellen Nachfragen vorzubeugen, natürlich habe ich die Lasttest mit ftp nur versuchsweise parallel gestartet normalerweise nutze ich nur das NFS streamen.

Vieleicht hat ja noch jemand eine Idee.

[storm]

Hi,

nur mal so 'ne Frage: weil du schreibst bis knapp über 2GB, am Filesystem respektive
maximale Dateigrösse kann nicht liegen? Welches FS benutzt du denn?

ciao, frank

[L@w]

ich habe seit kurzem das selbe problem. bleibt bei dir der linux client hängen oder der server.

bei mir ist es so. wenn ich ein nfs vom server mount, dann geht noch alles. ich kann verzeichnisse auch durchsuchen aber wenn ich etwas kopieren bzw. starten will, dann hängt sich das komplette terminal auf nciht einmal strg+c hilft mehr

verwende debian sid und kernel 2.6.6

[schuettert]

@storm

Filesystem ist ext3 (max Dateigröße irgendwo im Terabyte bereich) nfs v3 also auch bis Terabyte. Außerdem splittet mein Streamingserver (d-box 2) automatisch nach 2GB und fängt eine neue Datei an. In die neue Datei werden auch noch mehrer MB (10 - 200 MB) geschrieben und dan plötzlich Peng keine Netzverbindung mehr.

[schuettert]

@L@w

schreibst du auf die NFS Freigabe oder liest Du? Wie sehen deine Netzwerkparameter aus (Collisionen usw.)? Welche Mountparameter verwendest Du?

Vieleicht finden wir ja irgendeine Gemeinsamkeit und können damit das Problem eingrenzen.

[L@w]

ich habe immer das problem wenn ich gnome auf die shares zugreifen will vorher geht es noch.

jetzt habe ich mit einem 2.4.23er kernel getestet, da bekomme ich zwar diesen fehler nicht mehr

Code: Alles auswählen

nfs warning: mount version older than kernel

aber nfs hängt unter gnome immer noch.

ausserdem bekomme ich auch noch folgende fehlermeldung

Code: Alles auswählen

Jun  2 20:47:50 overdose kernel: nfs: server tux4u not responding, still trying

hier noch meine /etc/exports am server (fedora core 2)

Code: Alles auswählen

/home/law/share          192.168.0.0/24(rw,sync)

[storm]

@schuettert:
Das deine dbox den Stress verursacht, kann man wohl ausschliessen. Mir würde
kein richtiger Grund einfallen, der zum Abbruch auf dem Server führen soll.
Wie lange dauern 2GB bei dir so ungefähr? Du könntest so gegen Annäherung
an diese 2GB mal tcpdump anwerfen und nachschauen, ob die Verbindung regulär
beendet wird, sprich RST, oder ob der Server nur von einem Paket auf's andere
verschwindet.
Wieder nur 'ne einfache Frage: läuft auf dem Server iptables? Quotas gibt's keine?

Man, da müssen doch irgendwelche abstrusen Fehlermeldungen auftauchen. Ich kann
mir das nur schwer vorstellen, dass der Server so einfach still den Dienst einstellt.
Ist der syslogd auf dem Server auf LOG_DEBUG gestellt?
Da du ja geschrieben hast, dass du mehrere Kernel probiert hast, kann man dem 2.6.6er auch pauschal nix in die Schuhe schieben. Aber insgesamt klingt das schon exotisch. :)

ciao, frank

[schuettert]

@storm

Also den Client schließ ich auch aus, da das Problem ja bei verschiedenen Clients auftritt (dbox, knoppix, debian woody unstable, Windowsclients). Auf dem Server läuft iptables, ich mache damit aber nur ein masquerade auf dem ppp0 (dsl uplink) interface, ansonsten sind momentan noch alle rules auf accept. Sobald die Sache mit dem NFS sauber läuft werden die Rules angepasst. Quotas benutze ich auch nicht.

Mit der dbox hängt die Zeit bis die 2 GB geschrieben sind natürlich von dem gesendeten DVB-Stream ab, ich rechne immer grob 2,5 GB für 90 min Film. Ich muß heute abend mal eine große Datei von meinem PC zum Server schieben und kann dann die benötigte Zeit messen. Bei meinen Versuchen letzte Woche ist mir der NFS Server immer nach ein paar MB um die Ohren geflogen. Aber ich versuche es heute Abend nochmal mit veränderten mountoptionen. Ich glaube auch nicht das es irgend etwas mit der größe der zu schreibenen Datei zu tun hat. Wenn ich viele kleine Dateien schreibe bekomme ich den selben Efekt.

Der syslogd sollte bei mir eigendlich alle debugmessages mitschreiben.
Der Eintrag in der /etc/syslog.conf ist

Code: Alles auswählen

*.* -/var/log/messages

In /var/log/messages finde ich aber nur den Eintrag das die ppp Verbindung unterbrochen wurde (läuft über das Ethernetinterface).

Code: Alles auswählen

Jun  2 21:01:13 firewall pppd[1466]: No response to 3 echo-requests
Jun  2 21:01:13 firewall pppd[1466]: Serial link appears to be disconnected.
Jun  2 21:01:19 firewall pppd[1466]: Connection terminated.

Der NFS Server läuft auch weiterhin es ist halt nur noch interner Netzwerkverkehr über das Ethernetinterface möglich. Kann der NFS Serverprozeß irgendwie den Treiber der Netzwerkkarte schießen? Wie gesagt nachdem ich

Code: Alles auswählen

/etc/init.d/networking restart

ausgeführt habe läuft wieder alles. Leider finde ich auch keinerlei Einträge im Kernellog. Am IP Stack kann es ja eigentlich nicht liegen da ich sonst ja nicht eth0 bzw 127.0.0.1 local anpingen könnte.

Mit tcpdump mitzutracen habe ich bisher noch nicht versucht, werde ich heute abend aber auch mal testen.

[gucki]

das könnte das problem sein. u:u. kriegt der pppd seine pakete wegen der netzlast nicht durch und bricht ab. spendier ihm doch mal nee eigene Netzwerkkarte.

[Bert]

das könnte das problem sein. u:u. kriegt der pppd seine pakete wegen der netzlast nicht durch und bricht ab. spendier ihm doch mal nee eigene Netzwerkkarte.

Eher unwahrscheinlich. Fliegt Dir nur die pppd Verbindung weg oder gehen auch die lokalen (ethx) Verbindungen verloren?
Eventuell kannst Du mal mit den EchoRequest Optionen in /etc/ppp/peers/dsl-provider was tunen.

[schuettert]

@Bert

Solange ich local teste scheint alles wunderbar zu sein, eth0 und lo sind local erreichbar aber eth0 ist von Rechnern aus dem gleichen LAN-Segment nicht mehr erreichbar und vom Server aus kann ich auch keine anderen Rechner mehr erreichen (vergleichbar mit der Situation wenn man das Netzwerkkabel abzieht). Daher kommt ja meine Vermutung das es sich um ein Treiberproblem handelt was aber nur in Verbindung mit NFS write auftritt. Wie weiter oben schon geschrieben habe ich mit ftp (bei erheblich höheren Netzwerkdurchsatz) keinerlei Probleme. Das Problem muß meiner meinung nach unterhalb der IP Schicht (OSI Schicht 3) auftreten, da andere Protokolle wie z.B. LCP (OSI Schicht 2b)auch davon betroffen sind. Nur, normalerweise ist es diesen Schichten total egal ob ich nfs oder ftp als Protokoll der höheren Schichten benutze.

@gucki

Auch wenn ich den pppd deaktiviere habe ich das selbe Problem bei NFS write.

@all
Da das Problem scheinbar nur bei schreiboperationen auf den NFS Share auftritt schließe ich probleme beim Festplattenhandling auch nicht grundsätzlich aus. Folgene Gedankengänge habe ich gerade:
-IRQ Problem? -> unwarscheinlich da der selbe IRQ bei schreiben und lesen verwand wird. Meine momentane Config eth0->IRQ3, ide0->IRQ 14. Alle IRQ sind nur einmal belegt.
-Speicherprobleme? -> unwarscheinlich, da der Fehler genau reproduzierbar ist und nach einem Netzwerk restart wieder alles läuft
-Hardwareproblem? -> unwarscheinlich da der Fehler bis her nur bei NFS aufgetreten ist

Überlegungsansatz: Was passiert und welche Komponenten (HW,SW) werden bei einem NFS write beansprucht die bei NFS read, ftp, http, ssh, dns, smtp nicht oder anders beansprucht werden. Und vor allen Dingen wie kann ich hierfür an debug Meldungen kommen (außer alle Prozesse mit strace zu starten)? Die Hardware hat uptimes von 30 Tagen und mehr bisher ohne zu murren überstanden, bis auf wenn ich NFS write mache.

[gucki]

um die Netzwerkkarte und dessen Treiber auszuschliessen könnteste ja mal die Netzwerkkarte gegen eine tauschen die einen anderen Treiber benötigt

nur so nee Überlegung

[schuettert]

@gucki

Netzwerkkartentausch habe ich auch schon überlegt, das Problem ist nur das das eine PCMCIA Netzwerkkarte ist. Ich muß mal gucken ob ich mir irgendwo eine andere leihen kann. Ich habe noch eine orinoco WLAN Karte die ich dafür verwenden könnte, ich weiß aber nicht ob ich durch das WLAN nicht die Ergebnisse verfälsche.

Vieleicht kann ich das heute abend auch noch ausprobieren.

[storm]

Hi,

Ist dein Kernel ein fertiges Image oder hausgemacht? Hast du irgendwelche EXPERIMENTAL optionen an? Vielleicht kannst du dir mal nen test-Kernel bauen,
in dem nur die nötigsten Module drin sind. Möglich wäre auch den neuen gleich
mit Kernel-Hacking->Kernel-debugging zu bauen. Die Option ist für sowas drin.

Wenn das alles nix weiter bringt, solltest du mal auf LKML posten. Die können dir bei
der Problem-Lokalisierung noch eher Tipps geben. Aber zum Beispiel über Google
ist schon nix vergleichbares zu finden.

ciao, frank

--
Latein: empty!

[schuettert]

HI,

ich habe den vorcompelierten Kernel von Debian genommen, der ist komplett modularisiert und ich habe eigentlich nur die benötigten Module geladen. Aber ich werde mir mal einen eigenen Kernel bauen und schaun was dann passiert (wird wohl leider erst Montag oder Dienstag klappen).

Meine Tests gestern Abend waren alle erfolglos:
- andere Netzwerkkarte (Level One FPC-0103TX mit tulip treiber) Rechner hängt sich komplett auf, das ist aber ein Problem was nach einiger Zeit unabhängig von NFS auftaucht.
- tcptrace: das letzte was im trace zu sehen ist, ist das alle noch ausstehenden NFS write Operationen positiv vom Server bestätigt werden, konnte gestern leider nicht mehr prüfen ob die auch den client erreichen. Eventuell werden die ja nur auf das schon tote Interface ausgegeben. Dabei ist mir aufgefallen, das bei NFS (udp) für jedes Datenpacket ein neuer IP Port verwandt wird. Kann es sein das der NFS Server Probleme bekommt weil die Ports irgendwie aus dem Ruder laufen. Folgendes war nämlich auffällig. Beim ersten Versuch mit laufenden tcpdump wurden ca. 2,5 GB an Daten geschrieben, bei den nachfolgenden Versuchen wurden immer nur einige wenige MB an Daten geschrieben.

-Lasttest: Ich habe einfach mal versucht sowohl von der dbox als auch vom PC parallel auf das Freigabeverzeichnis zu schreiben, das funktioniert bis zum üblichen Abbruch wunderbar. Also vermute ich das es keine Netzlastprobleme gibt

Ich hoffe das ich am Dienstag so weit bin, dass ich wenigstens die Doppelfolge von "Die lieben Kollegen" auf Eins MuXx mitstreamen kann. Die ersten beiden Folgen waren nämlich Spitze, habe aber leider nur die erste gestreamt bekommen (bis auf die ersten zwei oder drei Minuten).

[storm]

HI,
...
- tcptrace: .... Dabei ist mir aufgefallen, das bei NFS (udp) für jedes Datenpacket ein neuer IP Port verwandt wird. Kann es sein das der NFS Server Probleme bekommt weil die Ports irgendwie aus dem Ruder laufen. Folgendes war nämlich auffällig. Beim ersten Versuch mit laufenden tcpdump wurden ca. 2,5 GB an Daten geschrieben, bei den nachfolgenden Versuchen wurden immer nur einige wenige MB an Daten geschrieben.
...

autsch, das sollte eher nicht so sein. Da nur maximal 65535(?) Ports vorhanden sind, bekommt er beim erreichen der Grenze keinen neuen mehr. Da müsste er sich doch aber melden!? Nur was soll die Ursache dafür sein. Ich hab keine Ahnung, warum er sich so
verhält. Und da in deinen Versuchen mit ftp das andere Protokoll genutzt wird,
sollte da dieser Fehler nicht auftauchen.
Vielleicht kann jemand von den Mitlesern/-schreibern das anhand eines funktionierenden
NFS-Servers mal verifizieren, speziell den Teil mit den Ports. Ich könnte das ehestens nächste Woche mal testen.

ciao, frank

[storm]

da mir das keine Ruhe gelassen hat, hab ich doch gleich noch nen Server aufgesetzt
und mit einer OSX-Box Daten draufgepackt, allerdings nur bis 1,5GB.
Das was du in deinem Trace vermutlich gesehen hast, waren nicht die Port-Nummern,
die so schnell ansteigen, sondern die Transaction-ID's.
Vgl.: man tcpdump - section NFS Requests and Replies

ciao, frank

[schuettert]

Jau, das waren die Transaction IDs. Arbeite zwar oft mit tcpdump, habe bisher aber noch nie NFS debuggen müssen und deshalb die Ausgabe nach alter Gewohnheit interpretiert. OK jetzt wo ich etwas genauer hingeschaut habe ist mir auch aufgefallen das die Zahlen nicht im 40.000 sondern 400.000 Bereich sind und damit keine IP V4 Portnummern sein können. Na ja passiert halt.

Bei dem schönen Wetter habe ich momentan auch ganz ehrlich gesagt nicht so richtig Lust zu Hause in der Wohnung große Forschungsprojekte zu betreiben. Ich werde heute Abend mal versuchen ob ich auf einen anderen Debian PC problemlos NFS streamen kann. Wenn das klappt weiß ich wenigstens das der Wurm nicht im eigentlichen NFS Server Daemon steckt.

Eventuell bau ich heute auch noch mal einen neuen Kernel für den Laptop.

[libiko]

Hallo Leutz.

Ich hatte vor kurzem auch das Problem, dass bei Größeren Datentransaktionen die (Wlan-)Verbindung abgebrochen ist.

Das Problem bei mir war eine fehlerhafte Firmware auf der PCI-Wlan-Karte im Server.
Nach einem Firmware-Upgrade auf die neueste Version hat wieder alles funktioniert.

Sollte das Problem bei Euch auch in einem Wlan-Netzwerk auftauchen und dabei Prism-Hardware im Spiel sein mal folgende Seite checken:
http://linux.junsun.net/intersil-prism/

mfg Robert

[schuettert]

Hi,

an Firmeware kann es eigentlich nicht liegen, da ich eine PCMCIA Ethernet Karte verwende und so viel ich weiß, wird dort keine Firmeware geladen. Aber trotzdem Danke für den Tipp. Ich habe jetzt das ganze etwas nach hinten geschoben, da ich momentan nicht so viel Zeit dafür habe. Sobald ich etwas neues herausfinde melde ich mich aber auf jeden Fall noch mal.

Bis dann