Re: An interesting anomaly in NFS client...

On Thu, Nov 7, 2024 at 2:09 PM Mark Johnston <markj@freebsd.org> wrote:
>
> On Thu, Nov 07, 2024 at 07:28:59AM +0200, Andriy Gapon wrote:
> > On 07/11/2024 02:43, George Neville-Neil wrote:
> > > Howdy,
> > >
> > > We've been digging into an interesting possible issue in the FreeBSD NFS
> > > client. Here is the scenario. I have a FreeBSD VM on my Mac, the Mac is
> > > the NFS server, the VM is the client. I then attempt to build an out of
> > > tree kernel module that I'm working on. The build looks like it's
> > > hanging for 1.5 seconds, and when we look at the packets (pcap file
> > > attached) we see a ton of GETATTRs over the first 1.5 seconds. I've put
> > > the pcap up here: oct_8_2024.pcapng <https://
> > > people.freebsd.org/~gnn/oct_8_2024.pcapng>
> > >
> > > I also note that an issue was raised on the forums that seems similar,
> > > way back between FreeBSD 10 and 11:
> > >
> > > https://forums.freebsd.org/threads/nfs-cache-misses-after-upgrading-to-11-1-
> > > from-10-3.65491/
> > > <https://forums.freebsd.org/threads/nfs-cache-misses-after-
> > > upgrading-to-11-1-from-10-3.65491/>
> > >
> > > I'm seeing this on 15 currentish (last few months).
> >
> > Could it be just make checking for stale targets?
> > I.e., stat-ing various files to check their timestamps.
All I can tell you is that the GETATTRs all check directories (at
least all the ones
I looked at). They all appear to be different directories.

Btw, if you have not already done so, look at the packet trace in wireshark.
It actually knows how to decode NFS.

rick

>
> I suspect it is from this line in sys/conf/config.mk:
>
> __MPATH!=find ${SYSDIR:tA}/ -name \*_if.m
>
> This is running a find command over all of sys/, so it'll stat about
> 35000 files.  I believe it's from
> https://cgit.freebsd.org/src/commit/?id=12f05b84463baacfada5a79eaed061a4899d98aa
>