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? > > 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. Trond or Anna, will you take this series for mountstats or are you opposed to it? I think it is useful in conjuction with the tracepoints because it is always on and easy to know which mount is involved (we often start with a customer saying mount XYZ has some issue or is hanging). If you see problems or want other testing please let me know. Thanks!
