lkml.org 
[lkml]   [2007]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [NFS] rpc.mountd crashes when extensively using netgroups
On Tue, 31 Jul 2007 10:48:24 -0400
"J. Bruce Fields" <bfields@fieldses.org> wrote:

> On Mon, Jul 30, 2007 at 02:55:14PM +0200, Stefan Walter wrote:
> > There are however two issues for which we could not find an easy
> > solution:
> >
> > 1. For every client rpc.mountd and the kernel seem to exchange
> > and use lists with _all_ netgroups used in exports that are
> > relevant for granting permission to some share for a particular
> > client. We could imagine two optimizations here:
> >
> > * Resolve netgroups and only put the (member) netgroups that
> > contained the host name that would be used to authorize
> > a mount in the list.
> >
> > * Use the list of mounted paths per client and only put the
> > netgroup(s) used to export paths that are actually mounted
> > on a client.
> >
> > This also caused us severe performance problems because
> > rpc.mountd queries all these netgroups. We were initially using
> > a LDAP and mouting a directory took up to ten seconds
> > during which rpc.mountd was busily querying the LDAP server.
> > We got this down to two seconds using file based netgroups.
> >
> > 2. Using a fixed size for NFSCLNT_IDMAX does not scale. Mounting
> > shares on a client for which the 'if' clause of the quick fix
> > becomes true will not be possible. We thought about enlarging
> > NFSCLNT_IDMAX and using a custom kernel but dropped the idea.
> >
> > Our ultimate goal is to get Red Hat fix the code in nfs-utils 1.0.6
> > that is used in RHEL4. A first step would be to get a suitable fix in
> > the current nfs-utils.
>
> That's an interesting problem. Thanks for the report!
>
> I don't believe that long comma-delimited string actually has any
> meaning to the kernel--as far as the kernel is concerned, it's just an
> opaque object that will be passed back to mountd later (along with a
> path name) to get export options.
>
> So I suppose that string could be replaced by a hash, or maybe even just
> by the ip address of the particular host--the disadvantage to the latter
> being that it would require the kernel to keep a separate export for
> each client address.
>
> --b.
>

I started having a look at this today. The original patches that I
proposed to clean up the rmtab a few months ago also eliminated this
comma-delimited string. Neil had valid objections to it at the time,
but if we switched to using the IP address as a cache key like Bruce
describes then doing that becomes more reasonable.

The only downside I see is the one Bruce points out -- the size of
the kernel export cache would increase. I don't have a feel for whether
this is a show stopper, however.

Neil, do you have thoughts on what you'd consider a reasonable approach
to fixing this?

--
Jeff Layton <jlayton@redhat.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-08-02 17:37    [W:2.162 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site