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

[Chuck Lever]

On Jan 22, 2009, at Jan 22, 2009, 10:19 AM, Steve Dickson wrote:
> 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...

Choosing mount was reasonable, as it's simple.  The discussion we are  
having about what tool is right for the job would have probably been  
less interesting if you had stuck with the I/O path.

The big picture though, is what do we need to do to make it easier to  
troubleshoot and solve problems.  That is a much bigger question than  
how we report errors.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com