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
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
