XPost: linux.debian.kernel   
   From: carnil@debian.org   
      
   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,relat   
   me,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tc   
   ,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,relat   
   me,vers=4.2,rsize=1047672,wsize=1047532,namlen=255,hard,proto=tc   
   ,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   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)