On Mon, Jun 03, 2019 at 02:56:29PM -0400, Chuck Lever wrote: > > On Jun 3, 2019, at 2:53 PM, Dave Wysochanski <dwysocha@xxxxxxxxxx> wrote: > > On Fri, 2019-05-31 at 09:25 -0400, Chuck Lever wrote: > >>> On May 30, 2019, at 6:33 PM, Bruce Fields <bfields@xxxxxxxxxxxx> > >>> wrote: > >>> On Thu, May 30, 2019 at 06:19:54PM -0400, Chuck Lever wrote: > >>>> We now have trace points that can do that too. > >>> > >>> You mean, that can report every error (and its value)? > >> > >> Yes, the nfs_xdr_status trace point reports the error by value and > >> symbolic name. > > > > The tracepoint is very useful I agree. I don't think it will show: > > a) the mount > > b) the opcode > > > > Or am I mistaken and there's a way to get those with a filter or > > another tracepoint? > > The opcode can be exposed by another trace point, but the link between > the two trace points is tenuous and could be improved. > > I don't believe any of the NFS trace points expose the mount. My testing > is largely on a single mount so my imagination stopped there. Dumb question: is it possible to add more fields to tracepoints without breaking some kind of backwards compatibility? I wonder if adding, say, an xid and an xprt pointer to tracepoints when available would help with this kind of thing. In any case, I think Dave's stats will still be handy if only because they're on all the time. --b.
