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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
