Dear Maik,
On Tue, Feb 24, 2026 at 11:32:14AM +0100, Maik Nergert wrote:
> Dear Salvatore,
>
> thanks for your quick response and brilliant tutorial! :)
Kudos goes to the original draft for this tutorial done by Uwe
Kleine-Koenig :)
> First: I couldn't reproduce the problem with a Debian (Bookworm) NFS Server.
> The bug report referred to shares provided by two different Dell EMC
> (Isilon) systems.
Oh, so that will not become easy to debug as well server side :(
> Second: Yes, the shares are mounted via automount, but for my tests I
> mounted them manually before changing to the directory.
> The mount was always performed with "mount -t nfs -o vers=4.2" without
> specifying rsize/wsize.
Ack that is important information that we really have not another
layer inbetween.
> But with the help of git bisect, I was able to narrow down the commit! (see
> below)
>
>
>
> Now I suspected that inheritance wasn't working, so I explicitly specified
> rsize/wsize again when mounting, and then it worked again...
> But look: despite 1048576, mount only shows 1047532.
>
> # mount -t nfs -o vers=4.2 nfs-server:/ifs/nas01/share /data/share
> # mount
> nfs-server:/ifs/nas01/share on /data/share type nfs4
> (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=x.x.x.x,local_lock=none,addr=x.x.x.x)
>
> # dd if=/dev/zero of=testfile bs=4k count=100000
> dd: closing output file 'testfile': Input/output error
>
>
> # mount -t nfs -o vers=4.2,rsize=1048576,wsize=1048576
> nfs-server:/ifs/nas01/share /data/share
> # mount
> nfs-server:/ifs/nas01/share on /data/share type nfs4
> (rw,relatime,vers=4.2,rsize=1047672,wsize=1047532,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=x.x.x.x,local_lock=none,addr=x.x.x.x)
>
> # dd if=/dev/zero of=testfile bs=4k count=100000
> 100000+0 records in
> 100000+0 records out
> 409600000 bytes (410 MB, 391 MiB) copied, 1.07056 s, 383 MB/s
>
>
>
>
> 11:11 $ git bisect log
> git bisect start
> # status: waiting for both good and bad commits
> # good: [f6e38ae624cf7eb96fb444a8ca2d07caa8d9c8fe] Linux 6.1.158
> git bisect good f6e38ae624cf7eb96fb444a8ca2d07caa8d9c8fe
> # status: waiting for bad commit, 1 good commit known
> # bad: [0182cb5b74ee79448adf4f33a137ca34e209eb30] Linux 6.1.162
> git bisect bad 0182cb5b74ee79448adf4f33a137ca34e209eb30
> # bad: [0ce72df67e78a68c74bcd64d2f4959c4ec571897] dma/pool: eliminate
> alloc_pages warning in atomic_pool_expand
> git bisect bad 0ce72df67e78a68c74bcd64d2f4959c4ec571897
> # good: [4443fc58fcc283a9a7aa73f2f30e427296612ec7] softirq: Add trace points
> for tasklet entry/exit
> git bisect good 4443fc58fcc283a9a7aa73f2f30e427296612ec7
> # good: [935ad4b3c325c24fff2c702da403283025ffc722] comedi: pcl818: fix
> null-ptr-deref in pcl818_ai_cancel()
> git bisect good 935ad4b3c325c24fff2c702da403283025ffc722
> # good: [1ad2f81a099b8df5f72bce0a3e9f531263a846b8] ocfs2: relax BUG() to
> ocfs2_error() in __ocfs2_move_extent()
> git bisect good 1ad2f81a099b8df5f72bce0a3e9f531263a846b8
> # good: [4acd1dd5a1e37ea86f5c4a6c52de2ebfe24ad1e1] drm/amd/display: Fix
> logical vs bitwise bug in get_embedded_panel_info_v2_1()
> git bisect good 4acd1dd5a1e37ea86f5c4a6c52de2ebfe24ad1e1
> # good: [fcb91be52eb6e92e00b533ebd7c77fecada537e1] net/sched: sch_cake: Fix
> incorrect qlen reduction in cake_drop
> git bisect good fcb91be52eb6e92e00b533ebd7c77fecada537e1
> # good: [3df62bf15590d28f9e72916a8aa46bc769228988] Revert "nfs: ignore
> SB_RDONLY when mounting nfs"
> git bisect good 3df62bf15590d28f9e72916a8aa46bc769228988
> # bad: [3d26dfc67e0b179ed78b1526b47545026e660b9d] platform/x86: asus-wmi:
> use brightness_set_blocking() for kbd led
> git bisect bad 3d26dfc67e0b179ed78b1526b47545026e660b9d
> # good: [bc8c969b62677b8acf3282afc6f779f9e76b598c] Expand the type of
> nfs_fattr->valid
> git bisect good bc8c969b62677b8acf3282afc6f779f9e76b598c
> # bad: [c559c99796911ab972e84a68bf4d223b921ce212] fs/nls: Fix inconsistency
> between utf8_to_utf32() and utf32_to_utf8()
> git bisect bad c559c99796911ab972e84a68bf4d223b921ce212
> # bad: [732a5be2d49fcf01afa18009cfb6cafe7bd94314] NFS: Fix inheritance of
> the block sizes when automounting
> git bisect bad 732a5be2d49fcf01afa18009cfb6cafe7bd94314
> # first bad commit: [732a5be2d49fcf01afa18009cfb6cafe7bd94314] NFS: Fix
> inheritance of the block sizes when automounting
Thank you, that was why I asked about automounting because that commit
was somehow outstanding while checking which commits might be
candidate.
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?
I'm asking because of, cf nfs(5):
If an rsize value is not specified, or if the specified
rsize value is larger than the maximum that either client
or server can support, the client and server negotiate
the largest rsize value that they can both support.
and
If a wsize value is not specified, or if the specified
wsize value is larger than the maximum that either client
or server can support, the client and server negotiate
the largest wsize value that they can both support.
So I suspect the negotiated rsize and wsize is then not 1M, correct,
I.e what are the negotiated sizes?
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.
Regards,
Salvatore
