This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC][PATCH 0/5] NFS: trace points added to mounting path
Greg Banks wrote:
> I think both dprintks and trace points are the wrong approach for
> client-side mount problems. What you really want there is good and
> useful diagnostic information going unconditionally via printk(). Mount
> problems happen frequently enough, and are often not the client's fault
> but the server's or a firewall's, that system admins need to be able to
> work out what went wrong in retrospect by looking in syslog.
>
> But just because Steve chose an unfortunate example doesn't invalidate
> his point. There are plenty of gnarly logic paths in the NFS client and
> server which need better runtime diagnostics. On the server, anything
> involving an upcall to userspace . On the client, silly rename or
> attribute caching.
It appears I did pick an "unfortunate example"... since I was really
trying to introduce trace points to see how they could be used...
Maybe picking the I/O path would have been better...
>>> Not being an admin guy, I really don't have an answer for this... but
>>> I can say since trace point are not so much of a drag on the system as
>>> printks are.. with in timing issues using trace point would be a big
>>> advantage
>>> over printks
>>>
>>
> Well that argument works both ways. Several times now I've seen
> problems where a significant part of the debugging process has involved
> noticing correlations between timing of dprintks and syslog messages
> from other subsystems, like IPoIB or TCP. That's harder to do if the
> debug statements and printks go through separate mechanisms to userspace.
Yes... I have seen this an number of times and places... :-(
steved.