2024-03-22 11:12:14

by Roland Mainz

[permalink] [raw]
Subject: "svc_tcp_read_marker nfsd RPC fragment too large" with Linux 6.6 LTS nfsd ...

Hi!

----

After updating my Debian 11 and RHEL 9 installations with Linux kernel
6.6.20-rt25 I start getting the following error messages
"svc_tcp_read_marker nfsd RPC fragment too large".
Client side is Linux NFSv4.2 client (Debian&&RHEL, both default kernel
and Linux 6.6.20-rt25)+ms-nfs41-client HEAD.

Is this a know issue, and is there a patch for it ?

----

Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)


2024-03-25 16:40:32

by Benjamin Coddington

[permalink] [raw]
Subject: Re: "svc_tcp_read_marker nfsd RPC fragment too large" with Linux 6.6 LTS nfsd ...

On 22 Mar 2024, at 7:11, Roland Mainz wrote:

> Hi!
>
> ----
>
> After updating my Debian 11 and RHEL 9 installations with Linux kernel
> 6.6.20-rt25 I start getting the following error messages
> "svc_tcp_read_marker nfsd RPC fragment too large".
> Client side is Linux NFSv4.2 client (Debian&&RHEL, both default kernel
> and Linux 6.6.20-rt25)+ms-nfs41-client HEAD.
>
> Is this a know issue, and is there a patch for it ?


I could be mistaken, but isn't the server complaining that the client is
sending requests larger than ca_maxrequestsize?

Ben


2024-03-27 20:28:49

by Chuck Lever

[permalink] [raw]
Subject: Re: "svc_tcp_read_marker nfsd RPC fragment too large" with Linux 6.6 LTS nfsd ...

On Fri, Mar 22, 2024 at 12:11:44PM +0100, Roland Mainz wrote:
> Hi!
>
> ----
>
> After updating my Debian 11 and RHEL 9 installations with Linux kernel
> 6.6.20-rt25 I start getting the following error messages
> "svc_tcp_read_marker nfsd RPC fragment too large".
> Client side is Linux NFSv4.2 client (Debian&&RHEL, both default kernel
> and Linux 6.6.20-rt25)+ms-nfs41-client HEAD.
>
> Is this a know issue, and is there a patch for it ?

The "fragment too large" message means the incoming RPC frame has
the high-order bit set in its TCP record marker. It could mean:

1. The client is trying to send an RPC message that is split over
multiple RPC fragments. The Linux in-kernel RPC server does not
support that.

2. The TCP byte stream has gotten out of sync with the RPC
framing. That's a sign of a bug or misconfiguration somewhere,
though not necessarily on the NFS server.

Wireshark can help you sort it out.

--
Chuck Lever