Re: [RFC][PATCH 0/5] NFS: trace points added to mounting path

[Steve Dickson <SteveD@redhat.com>]

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.