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