ubuntuusers.de

NFS - RPC fragment too large.

Status: Ungelöst | Ubuntu-Version: Ubuntu 20.04 (Focal Fossa)
Antworten |

tachtler

Anmeldungsdatum:
15. April 2024

Beiträge: 5

Hallo,

ich habe einen lauffähigen NFS-Server (Ubuntu 20.04) und auch die Möglichkeit einen mount-point (Laptop, auch Ubuntu 20.04) erfolgreich zu mounten.

Allerdings habe ich seit kurzem das Problem, das der Datentransfer z.B. via rsync auf das NFS-share nach anfänglich kurzer Zeit auf wenige KiloByte abfällt und ich auf dem NFS-Server nachfolgende Meldungen im systemd-Journal zu sehen bekomme:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
[1100193.043409] RPC: fragment too large: 1195725856
[1100193.049820] RPC: fragment too large: 1195725856
[1100193.056398] RPC: fragment too large: 1195725856
[1100194.042955] RPC: fragment too large: 909129248
[1100194.634585] RPC: fragment too large: 1195725856
[1100196.813249] RPC: fragment too large: 1008750164
[1100197.392156] RPC: fragment too large: 1195725856
[1100197.949096] RPC: fragment too large: 369295618
[1100198.934351] RPC: fragment too large: 1347569952
[1100199.445306] RPC: fragment too large: 1986359923

Meine mount-Optionen aus meiner /etc/fstab sind nachfolgende:

1
nfs.server.domain.tld:/home /media/nfs/nfs03 nfs rw,nfsvers=4,sec=krb5p,nodev,_netdev,noauto,user 0 0

welche dann nach erfolgreichem mount wie folgt aussehen:

1
nfs.server.domain.tld:/home on /media/nfs/nfs03 type nfs4 (rw,nosuid,nodev,noexec,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=krb5p,clientaddr=[ipv6-REDACTED],local_lock=none,addr=[ipv6-REDACTED],_netdev,user)

Ein tcpdump gibt mir nachfolgende Informationen beim Datentransfer:

1
2
3
08:49:04.282561 IP6 laptop02.899 > nfs.server.domain.tld.nfs: Flags [P.], seq 30949537:30949893, ack 2810465, win 16132, options [nop,nop,TS val 2470410602 ecr 2503829262], length 356: NFS request xid 383315241 352 getattr fh 1,0/0
08:49:04.283042 IP6 nfs.server.domain.tld.nfs > laptop02.899: Flags [P.], seq 2810465:2810677, ack 30949893, win 20172, options [nop,nop,TS val 2503832736 ecr 2470410602], length 212: NFS reply xid 383315241 reply ok 208 getattr ERROR: unk 152
08:49:04.283060 IP6 laptop02.899 > nfs.server.domain.tld.nfs: Flags [.], ack 2810677, win 16132, options [nop,nop,TS val 2470410602 ecr 2503832736], length 0

Kann mir bitte hier jemand einen Hinweis zur Lösung des Problems geben? (Sind noch weitere Informationen notwendig, welche ich hier "posten" sollte?)

Danke schon in Voraus. Grüße.

dingsbums

Anmeldungsdatum:
13. November 2010

Beiträge: 3782

seit kurzem das Problem

tachtler

(Themenstarter)

Anmeldungsdatum:
15. April 2024

Beiträge: 5

Hallo dingsbums,

kann das wirklich an dem Kernel oder einem bestimmten Kernel-Parameter liegen?

Serverseitig wurde keine Hardware verändert.

Noch weitere Ideen?

Danke und Grüße Klaus.

kB Team-Icon

Supporter, Wikiteam
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 9629

Wohnort: Münster

tachtler schrieb:

[…] NFS-Server […] Laptop

Und was befindet sich zwischen den beiden Rechnern? (Brücken, Tunnel, Brandmauern, Fährverbindungen, …)

dingsbums

Anmeldungsdatum:
13. November 2010

Beiträge: 3782

kann das wirklich an dem Kernel oder einem bestimmten Kernel-Parameter liegen?

Warum hast du es nicht einfach ausprobiert? Dauert keine 5 min, und man kann es ausschließen oder nicht. Oder willst du erst 3 Tage lang weitere Ideen sammeln? 😉

tachtler

(Themenstarter)

Anmeldungsdatum:
15. April 2024

Beiträge: 5

kB schrieb:

tachtler schrieb:

[…] NFS-Server […] Laptop

Und was befindet sich zwischen den beiden Rechnern? (Brücken, Tunnel, Brandmauern, Fährverbindungen, …)

Hallo kB,

zwischen den beiden Servern befindet sich die selbe unveränderte Hardware, welche auch vor den Problemen im Einsatz war. (Was sicherlich keine Brücken und Fährverbindungen sind) Ich hatte eher auf konstruktive Hilfe gehofft - außerdem kann man im TCP-Dump sehen, das nicht die Verbindung - physischer Art - das Problem zu sein scheint.

Grüße

tachtler

(Themenstarter)

Anmeldungsdatum:
15. April 2024

Beiträge: 5

dingsbums schrieb:

kann das wirklich an dem Kernel oder einem bestimmten Kernel-Parameter liegen?

Warum hast du es nicht einfach ausprobiert? Dauert keine 5 min, und man kann es ausschließen oder nicht. Oder willst du erst 3 Tage lang weitere Ideen sammeln? 😉

Hallo dingsbums,

ich werde einen Neustart des NFS-Servers mit der vorhergehenden Kernel-Version versuchen und hier berichten. Es nutzen ein paar mehr Leute den NFS-Server, so dass ich den nicht einfach mal so unter Tags neu starten kann, bzw. will.

Ich hatte darauf gehofft, dass jemand bereits das oder ein ähnliches Problem hatte und eine Lösung auf der Basis von Konfigurationseinstellungen hat.

Grüße

dingsbums

Anmeldungsdatum:
13. November 2010

Beiträge: 3782

Es nutzen ein paar mehr Leute den NFS-Server

Bedeutet, nur dein Client hat das Problem und andere Systeme nicht? Warum schreibst du das nicht gleich? Dann kannst du doch prima zwischen dem Problem-PC und anderen Systemen vergleichen.

tachtler

(Themenstarter)

Anmeldungsdatum:
15. April 2024

Beiträge: 5

dingsbums schrieb:

Es nutzen ein paar mehr Leute den NFS-Server

Bedeutet, nur dein Client hat das Problem und andere Systeme nicht? Warum schreibst du das nicht gleich? Dann kannst du doch prima zwischen dem Problem-PC und anderen Systemen vergleichen.

Hallo dingsbuns,

nein, alle haben das Problem.

Allerdings nur beim NFS-Zugriffen, nicht bei z.B direktem rsync via TCP.

Grüße

Antworten |