----- On 22 Nov, 2020, at 03:03, bfields bfields@xxxxxxxxxxxx wrote: >> The workload I have been looking at recently is a NFSv3 re-export of a NFSv4.2 >> mount. I can also say that it is generally when new files are being written to >> a directory. So yes, the files and dir are changing at the time but I still >> didn't expect to see so many repeated getattr neatly bundled together in short >> bursts, e.g. (re-export server = 10.156.12.1, originating server 10.21.22.117). > > Well, I guess the pre/post-op attributes could contribute to the > problem, in that they could unnecessarily turn a COMMIT into > > GETATTR > COMMIT > GETATTR > > And ditto for anything that modifies file or directory contents. But > I'd've thought some of those could have been cached. Also it looks like > you've got more GETATTRs than that. Hm. Yea, I definitely see those COMMITs surrounded by GETTATTRs with NFSv4.2... But as you say, I get way more repeat GETATTRs for the same filehandles. I switched to a NFSv4.2 re-export of a NFSv3 server and saw the kind of thing - sometimes the wire would see 4-5 GETTATRs for the same FH in tight sequence with nothing in between. So then I started thinking.... how does nconnect work again? Because my re-export server is mounting the originating server with nconnect=16 and the flurries of repeat GETATTRs often contain a count in that ballpark. I need to re-test without nconnect... Maybe that's how it's supposed to work and I'm just being over sensitive after this iversion issue. Daire -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cachefs
