Re: nfs server issues

On Tue, 2026-07-07 at 15:54 -0700, Michael Halstead wrote:
> On Tue, Jul 7, 2026 at 1:52 AM Richard Purdie <[email protected]> wrote:
> > On Sat, 2026-07-04 at 12:41 -0700, Rick Macklem wrote:
> > > On Sat, Jul 4, 2026 at 1:05 AM Richard Purdie
> > > <[email protected]> wrote:
> > > > 
> > > > nfsstat -E -s
> > > > Server Info:
> > > >       Getattr      Setattr       Lookup     Readlink         Read        Write
> > > >   17354100116   1674996998   5136769057        40544  18429670397    986443058
> > > >        Create       Remove       Rename         Link      Symlink        Mkdir
> > > >             0     98646613    119865835     17071853            0            0
> > > >         Rmdir      Readdir     RdirPlus       Access        Mknod       Fsstat
> > > >             0   1655544711            0   4129535844            0            0
> > > >        FSinfo     pathConf       Commit      LookupP      SetClId    SetClIdCf
> > > >             0            0      8723436            0            0            0
> > > One more thing to note. The # of Commits is much smaller than the # of Writes
> > > on the top line. This "hints" that a lot of the Writes are being done File_sync.
> > > (To check that, you'd need to capture packets and look at them in wireshark.)
> 
> 
> I've captured data
> at https://valkyrie.yocto.io/pub/non-release/mtest/nfs_capture2.pcap.
> zst from a fresh reboot running the testlock.py for about 100MB of
> data and umounting the filesystems. Please let me know if this
> reveals the issue or what else I can offer. 

Thanks Michael. I think that didn't have enough parallel test scripts
running. This is one I just captured with more parallelism (4 clients),
just tracing one of them:

https://valkyrie.yocto.io/pub/non-release/mtest/rp_capture.pcap.zst

This one has a lot of NFS4ERR_STALE in it which I suspect is what we
were looking for...

Cheers,

Richard