Fehlermeldung bei NFS: RPC: bad TCP reclen 0x00020090 (large)

[AndreasMeier]

Hallo zusammen,

seit kurzem macht mein Fileserver ein paar Probleme.
Und zwar kann ich nach ner Zeit plötzlich nicht mehr auf die NFS-Laufwerke zugreifen.

In den Logfiles finde ich folgende Fehlermeldung:
RPC: bad TCP reclen 0x00020090 (large)

Wenn ich nach "bad TCP reclen" google, erhalte ich nur Beiträge, die ich nicht verstehe, daher wollte ich hier fragen, ob das Problem evtl. bekannt ist und was ich dagegen machen kann.

danke und Gruß
Andreas

[BedriddenTech]

Das klingt, als würde der Client größere TCP-Segmente schicken, als der Server verarbeiten kann. Guck Dir mal die rsize/wsize-Parameter (auf Seite des Clients) an. Prüf auch mal, ob unter Umständen ein alter Standard genutzt wird (NFSv2 z. B.)

[AndreasMeier]

Hallo,

danke für Deine Antwort. Auf dem Client und dem Server läuft jeweils Version 1.10 der NFS-Common-Utils.
Auf dem Client find ich keine Einstellungen, die man treffen kann.
Ich mounte das NFS-Verzeichnis direkt per fstab.
Allerdings finde ich auf dem Client in der /var/log/messages:
kernel: nfs: server ip-adresse not responding, timed out
kernel: lockd: server ip-adresse not responding, still trying

Ich denke mal, dass es nicht am Client liegt, sondern am Server.
Dort irgendwelche Ideen, wo ich am besten ansetzen kann ?

[BedriddenTech]

Ich meinte damit eigentlich nicht die Version der NFS-Utils, sondern die Protokollversion, mit der der Mountvorgang geschieht.

Laufen denn die notwendigen Dienste aufm Server ohne Fehlermeldungen (also portmapper und die NFS-Dienste)? Welche Protokollversion willst Du überhaupt nutzen? Vorsicht bei NFSv3: Für den mountd wird der Port, wenn Du nichts einstellst, zufällig ausgewählt -- kann problematisch werden, wenn Du eine restriktive Firewall einsetzt.

[AndreasMeier]

Hm, sorry, wenn ich mich etwas anstelle, aber ich weiß im Moment noch nicht, was Du mit Protokollversion meinst.

Ich mounte (autom.) das NFS-Share per fstab mit folgenden Eintrag:


192.168.1.1:/nfs_share /home/andreas/nfs_share nfs bg,soft,intr,retry=2 0 2


Ging lange Zeit ganz gut, seit kurzem mountet er beim Starten nicht mehr, sondern ich muss manuell nachmounten.
Ich hab gestern allerdings auf dem Server von NFS3 auf NFS4 umgestellt.
Hab heute keinen einzigen Absturz gehabt (zum Glück, gestern hatte ich dadurch bereits Daten verloren - leider!!), auch keine RPC-Fehler mehr (hab nen tail -f auf /var/log/messages mitlaufen lassen).
Allerdings muss ich dazu sagen, dass ich heut auch weniger auf dem NFS-Laufwerk gearbeitet hatte.

Fehlermeldungen gab es gestern nur auf dem Server und (eigentlich) nur die oben gepostete. Komm heut leider nicht mehr an den Server, sonst könnte ich nochmal nachschauen, ob da noch mehr war.
Nach was kann ich denn konkret schauen (nfs, portmap etc.) ?

Das mit dem zufällig gewählten Port seh ich als unkritisch an (auch wenn ich vorher NFS3 hatte), da alles im internen Netz läuft und intern wird nix durch ne Firewall blockiert (NFS läuft auch nur intern).

Danke und Gruß
Andreas

[BedriddenTech]

Mit Protokollversion meine ich -- genau -- die Version des NFS-Protokolls, die Du benutzt. Das ist seit vorestern dann wohl NFSv4. :) Kleiner Tipp: Wenn Deine Installation noch nicht so sicher ist -- sprich, noch Abstürze geschehen --, solltest Du die Option "no_wdelay" nutzen. Das wirkt natürlich böse auf die Geschwindigkeit, aber lieber sicher als schnell. ;)

Wenn Fehlermeldungen kommen, dann sind sie entweder im Systemlog (messages) oder im Kernel Log (dmesg); wäre interessant zu sehen, welche Quelle die Meldungen ausspuckt. Desweiteren könntest Du mal mit den Mount-Optionen "rsize" und "wsize" experimentieren (z. B. die mal auf 8192 setzen -- immer 2^x) und schaun, ob es dann besser wird. Vielleicht ist aber auch die Umstellung von NFSv3 auf NFSv4 schon der Grund für die spontante Problemlösung.

Gut wäre, wenn Du dafür mal ein temporäres Verzeichnis auf dem Server freigibst und Lese- und Schreibttests
durchführst. Mittels Skripten und dd kann man da recht schnell ein paar typische Szenarien simulieren. :)

Nebenbei: Welche Kernelversionen sind eigentlich im Einsatz?

[AndreasMeier]

Auf dem Server lief bis vor kurzem ein 2.6.18er Kernel, der bei Debian Etch halt Standard war.
Seit kurzem ist ja ein Update für Etch rausgekommen und ich hab einen 2.6.24 oder 2.6.25er-Kernel probiert.
Zum gleichen Zeitpunkt habe ich aber auch die Probleme mit NFS erhalten.

Wie ich vorgestern von NFS3 auf NFS4 gewechselt habe, hab ich dann auch die neue Kernel-Version wieder runtergeworfen und wieder den 18er-Kernel genommen.
Freitag und gestern lief der Betrieb recht stabil, wobei ich nicht allzuviel auf dem NFS-Share machen musste/wollte. Schliesslich musste ich meine verloren gegangene Datei/Arbeit neu aufbauen.

Ich hab nochmal nach "RPC bad TCP reclen" gesucht. Ein Kumpel hat das ebenfalls gemacht und gemeint, er hätte dort immer ne bestimmte Kernel-Version hinter den Meldungen gesehen.
Vielleicht ist durch meinen Wechsel zurück auf den 18er-Kernel der Spuk wieder beendet. Werd das die nächste Woche genau beobachten und berichten.

Kannst Du das mit der Kernel-Version bestätigen ?

Danke und Gruß
Andreas

[BedriddenTech]

Ja, ziemlich. Solltest auf 2.6.26 oder größer wechseln, es gibt einen Bug, der damit in Zusammenhang steht und jetzt behoben wurde. :)

[AndreasMeier]

Danke, alles klar.