Date: Fri, 08 Nov 2024 09:47:59 -0800 From: George Neville-Neil <gnn@neville-neil.com> To: Rick Macklem <rick.macklem@gmail.com> Cc: Mark Saad <nonesuch@longcount.org>, freebsd-net@freebsd.org Subject: Re: An interesting anomaly in NFS client... Message-ID: <884A1DD9-B512-45B5-8520-F4E458105AC0@neville-neil.com> In-Reply-To: <CAM5tNy55mJABnJBRL3FMeqtwyeEQbRmBgP7nxO8J7zqROfdLtA@mail.gmail.com> References: <8187509e-c9fb-403f-8569-28ba58425cff@FreeBSD.org> <D1D03377-1A7B-47FA-B40D-2A30D0855F07@longcount.org> <9BD96F0F-363F-45BF-B3AF-BDEBD4B46175@neville-neil.com> <CAM5tNy7W9kHOFLoJWsU_1fU=%2BZ5OoDU7axw3izUv4GPWXpAF2A@mail.gmail.com> <DBB21A78-284C-4A97-892A-219E881D6DD8@neville-neil.com> <CAM5tNy55mJABnJBRL3FMeqtwyeEQbRmBgP7nxO8J7zqROfdLtA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8 Nov 2024, at 7:58, Rick Macklem wrote: > On Thu, Nov 7, 2024 at 9:41=E2=80=AFPM George Neville-Neil <gnn@neville= -neil.com> wrote: >> >> >> >> On 7 Nov 2024, at 13:59, Rick Macklem wrote: >> >>> On Thu, Nov 7, 2024 at 9:34=E2=80=AFAM George Neville-Neil <gnn@nevil= le-neil.com> wrote: >>>> >>>> >>>> >>>> On 7 Nov 2024, at 4:15, Mark Saad wrote: >>>> >>>>>> >>>>>> On Nov 7, 2024, at 12:29=E2=80=AFAM, Andriy Gapon <avg@freebsd.org= > wrote: >>>>>> >>>>>> =EF=BB=BFOn 07/11/2024 02:43, George Neville-Neil wrote: >>>>>>> Howdy, >>>>>>> We've been digging into an interesting possible issue in the Free= BSD 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. >>>>> >>>>> What are you using to run the vm ? What architecture is the vm ? Wh= at about the Mac ? >>>> >>>> qemu, aarch64, M3 Mac. >>>> >>>> I doubt this is the source of the issue. >>>> >>>> I was poking through the code and I wonder if a slight time skew mig= ht be an issue. I'm going to check into that. The VM and the Mac both u= s NTP to stay in sync with the world, but who knows... >>> Hi George, >>> >>> I'll take a look at the packet trace later, but... >>> >>> If you can easily reproduce the issue, do a: >>> # nfsstat -E -c -z >>> - before reproducing it, and a >>> # nfsstat -E -c >>> - after. Then look at the Cache Info: at the end of the output. >>> >> >> I'll give that a look, and the thing that Mark found is also interesti= ng. I might ask Warner about it tomorrow, we're both at the Dev Summit. > When I looked at the packet trace, I saw a lot of GETATTRs > for different directories. If they are different directories and not > the same ones over and over again, caching will not be the issue. > (Btw, the attribute caching code hasn't changed in decades, afaik.) > Looks like the answer is what Mark sent, and I talked to Warner and what = we do now is, if not great, still the right thing, and just isn't so happ= y on NFS. We use NFS in our work on kernel development because we develo= p on VMs to start. Other than this pause, world builds on a modern (M3) l= aptop are as fast on an average server (hurray SoCs) and when the thing c= rashes it reboots in seconds, rather than 10 minutes which is how long a = modern Dell server takes to do its hardware checks. The shorter answer from some folks is "use 9pfs because NFS (server) on M= acOS is sloooow" which I'll look into as well. Thanks for all the help, it's been an interesting journey ;-) > Have fun at the dev summit, rick > Doing our best! Best, George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?884A1DD9-B512-45B5-8520-F4E458105AC0>