On Thu, Jan 22, 2009 at 09:36:53AM +1100, Greg Banks wrote: > Chuck Lever wrote: > > > > > > I think we need to visit this issue on a case-by-case basis. > > Sometimes dprintk is appropriate. Sometimes printk(KERN_ERR). > > Sometimes a performance metric. > Well said. > > > Trond has always maintained that dprintk() is best for developers, but > > probably inappropriate for field debugging, > It's not a perfect tool but it beats nothing at all. > > and I think that may also > > apply to trace points. > It depends on whether distros can be convinced to enable it by default, > and install by default any necessary userspace infrastructure. The > most important thing for field debugging is Just Knowing that you have > all the bits necessary to perform useful debugging without having to > find some RPM that matches the kernel that the machine is actually > running now, and not the one that was present when the machine was > installed. On the mount case specifically: How far are we from the idea of a mount program that can identify most problems itself? I know its error reporting has gotten better.... I suppose the main feedback mount gets right now is an error code from the mount system call, and that may be too narrow an interface to cover most problems. Is there some way we can give mount a real interface it can use to find out this stuff instead of just dumping more strings into the logs? My main obstacle to judging a solution is that I don't have in mind a good list of (say) the top 10 problems that can cause the first mount to fail. Hm: - dns lookup of the server fails - server isn't reachable - server isn't running nfs - requested path isn't known to server or isn't exported - export is there, but requires more security - user doesn't have gss credentials - file permissions on the export are wrong ... --b. -- 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
