On Wed, 2024-01-24 at 17:12 -0500, Josef Bacik wrote: > On Wed, Jan 24, 2024 at 03:32:06PM -0500, Chuck Lever wrote: > > On Wed, Jan 24, 2024 at 02:37:00PM -0500, Josef Bacik wrote: > > > We are running nfsd servers inside of containers with their own network > > > namespace, and we want to monitor these services using the stats found > > > in /proc. However these are not exposed in the proc inside of the > > > container, so we have to bind mount the host /proc into our containers > > > to get at this information. > > > > > > Separate out the stat counters init and the proc registration, and move > > > the proc registration into the pernet operations entry and exit points > > > so that these stats can be exposed inside of network namespaces. > > > > Maybe I missed something, but this looks like it exposes the global > > stat counters to all net namespaces...? Is that an information leak? > > As an administrator I might be surprised by that behavior. > > > > Seems like this patch needs to make nfsdstats and nfsd_svcstats into > > per-namespace objects as well. > > > > > > I've got the patches written for this, but I've got a question. There's a > > svc_seq_show(seq, &nfsd_svcstats); > > in nfsd/stats.c. This appears to be an empty struct, there's nothing that > utilizes it, so this is always going to print 0 right? There's a svc_info in > the nfsd_net, and that stats block appears to get updated properly. Should I > print this out here? I don't see anywhere we get the rpc stats out of nfsd, am > I missing something? I don't want to rip out stuff that I don't quite > understand. Thanks, > > nfsd_svcstats ends up being the sv_stats for the nfsd service. The RPC code has some counters in there for counting different sorts of net and rpc events (see svc_process_common, and some of the recv and accept handlers). I think nfsstat(8) may fetch that info via the above seqfile, so it's definitely not unused (and it should be printing more than just a '0'). svc_info is a completely different thing: it's a container for the svc_serv...so I'm not sure I understand your question? -- Jeff Layton <jlayton@xxxxxxxxxx>
