On Tue, 31 Jul 2007 10:48:24 -0400 "J. Bruce Fields" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> - 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/
