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/
