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

Muntz, Daniel
2009-01-21T23:05:42Z

My favorite: when you try a Kerberos mount and one of the kernel modules
requried for this isn't loaded, mount gets ENOMEM and says "out of
memory"

-Dan

-----Original Message-----
From: J. Bruce Fields [mailto:bfields@fieldses.org]
Sent: Wednesday, January 21, 2009 2:56 PM
To: Greg Banks
Cc: Chuck Lever; Linux NFS Mailing list; Linux NFSv4 mailing list;
SystemTAP
Subject: Re: [RFC][PATCH 0/5] NFS: trace points added to mounting path

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@vger.kernel.org More majordomo info
at http://vger.kernel.org/majordomo-info.html