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...