On Tue, 2019-06-04 at 10:45 -0400, Bruce Fields wrote: > 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? Tracepoints are not to be considered an API. > 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. Given that someone who shall remain anonymous added the struct rpc_rqst to the struct xdr_stream for "debugging purposes", it should be quite possible to add both the XID and the xprt in this case. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
