Hi,
if you rollback to the old kernel, with the mount options as when you are able to trigger the problem, what will mount show for the negotiated wsize and rsize?
> So I suspect the negotiated rsize and wsize is then not 1M, correct, > I.e what are the negotiated sizes? Mounting without specific rsize/wsize: Kernel 6.1.158 negotiated (from Dell Powerscale OneFS aka Isilon) rsize=1047672,wsize=1047532 and no errors Kernel 6.1.162 negotiated rsize=1048576,wsize=1048576 and Input/output error Kernel 6.1.158 negotiated (from Debian Bookworm NFS) rsize=1048576,wsize=1048576 and no errors
One additional question: Do you have a test system exposing the
problem where you can try as well the kernel from trixie, unstable or
experimental to gather an idea if it affects still upper kernels? I'm
asking because 2b092175f5e3 ("NFS: Fix inheritance of the block sizes
when automounting") is in v6.19-rc1 and got backported to v6.18.2,
v6.17.13, v6.12.63, v6.6.120 and v6.1.160.
Linux trixie-test 6.12.73+deb13-amd64 mount -t nfs -o vers=4.2 Results in "rsize=1048576,wsize=1048576" and Input/output error mount -t nfs -o vers=4.2,rsize=1048576,wsize=1048576 Results in "rsize=1047672,wsize=1047532" and no errorsI would say that the commit corrected the wrong values (<1M to the correct 1M) and that in this case there is no problem with the kernel. It now looks much more like the "Powerscale OneFS" NFS server is somehow incorrect.
<1M works for us, so I think we should just specify a value for automount and live with it and create a Dell support ticket.
best regards, Maik
smime.p7s
Description: S/MIME Cryptographic Signature
