From: "J. Bruce Fields" <bfields@fieldses.org>
To: Neil Brown <neilb@suse.de>
Cc: nfs@lists.sourceforge.net,
Stefan Walter <stefan.walter@inf.ethz.ch>,
Jeff Layton <jlayton@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: rpc.mountd crashes when extensively using netgroups
Date: Fri, 3 Aug 2007 12:07:09 -0400 [thread overview]
Message-ID: <20070803160709.GD456@fieldses.org> (raw)
In-Reply-To: <18098.39541.547557.132952@notabene.brown>
On Fri, Aug 03, 2007 at 01:01:09PM +1000, Neil Brown wrote:
> The core issue is this:
>
> We need to map IPADDRESS to THING, and THING + PATH to EXPORTPOINT.
> (roughly).
> So what do we choose for "THING"?
>
> One obvious option is the dotted quad of the IP address.
> People tend to have large sets of similar clients, so doing this seems
> to be missing out on a valuable optimisation and adding bloat to the
> lookup tables in the kernel.
$ gdb vmlinux
GNU gdb 6.6-debian
...
(gdb) print sizeof(struct ip_map)
$1 = 40
(gdb) print sizeof(struct svc_export)
$2 = 136
Hm, OK, one-address-per-export loses.
> I guess we could use a hash and keep a hash table in mountd.
> So mountd:
> 1/ Generates the comma-separated name as needed, being careful to
> allocate enough space.
> 2a/ If this is small enough, write it to the kernel as is.
> 2b/ If it is too big, Find it in a table (adding if needed) and
> write the address of the table entry to the kernel
>
> When a THING + PATH request arrives:
> If THING looks like an address in the table, do the lookup to get
> the string.
>
> This would work to keep the strings in the kernel shorter, but is
> rather ugly - storing in the kernel addresses in a user-space program.
If you use an actual collision-free hash function then the result will
be reproduceable, so you don't have to depend on temporary information
in mountd.
> So maybe we want to combine the two workable approaches.
>
> Sometimes IPADDRESS maps to DOTTED_QUAD
> Sometimes IPADDRESS maps to LIST,OF,STRINGS,FROM,ETC,EXPORTS
>
> Possibly the choice could be based on a command line switch.
> In the absence of such a switch, it could be based on the number of
> entries in /etc/exports.
Seems OK.
--b.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
WARNING: multiple messages have this Message-ID (diff)
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Neil Brown <neilb@suse.de>
Cc: Jeff Layton <jlayton@redhat.com>,
Stefan Walter <stefan.walter@inf.ethz.ch>,
nfs@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [NFS] rpc.mountd crashes when extensively using netgroups
Date: Fri, 3 Aug 2007 12:07:09 -0400 [thread overview]
Message-ID: <20070803160709.GD456@fieldses.org> (raw)
In-Reply-To: <18098.39541.547557.132952@notabene.brown>
On Fri, Aug 03, 2007 at 01:01:09PM +1000, Neil Brown wrote:
> The core issue is this:
>
> We need to map IPADDRESS to THING, and THING + PATH to EXPORTPOINT.
> (roughly).
> So what do we choose for "THING"?
>
> One obvious option is the dotted quad of the IP address.
> People tend to have large sets of similar clients, so doing this seems
> to be missing out on a valuable optimisation and adding bloat to the
> lookup tables in the kernel.
$ gdb vmlinux
GNU gdb 6.6-debian
...
(gdb) print sizeof(struct ip_map)
$1 = 40
(gdb) print sizeof(struct svc_export)
$2 = 136
Hm, OK, one-address-per-export loses.
> I guess we could use a hash and keep a hash table in mountd.
> So mountd:
> 1/ Generates the comma-separated name as needed, being careful to
> allocate enough space.
> 2a/ If this is small enough, write it to the kernel as is.
> 2b/ If it is too big, Find it in a table (adding if needed) and
> write the address of the table entry to the kernel
>
> When a THING + PATH request arrives:
> If THING looks like an address in the table, do the lookup to get
> the string.
>
> This would work to keep the strings in the kernel shorter, but is
> rather ugly - storing in the kernel addresses in a user-space program.
If you use an actual collision-free hash function then the result will
be reproduceable, so you don't have to depend on temporary information
in mountd.
> So maybe we want to combine the two workable approaches.
>
> Sometimes IPADDRESS maps to DOTTED_QUAD
> Sometimes IPADDRESS maps to LIST,OF,STRINGS,FROM,ETC,EXPORTS
>
> Possibly the choice could be based on a command line switch.
> In the absence of such a switch, it could be based on the number of
> entries in /etc/exports.
Seems OK.
--b.
next prev parent reply other threads:[~2007-08-03 16:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-30 12:55 rpc.mountd crashes when extensively using netgroups Stefan Walter
2007-07-31 13:59 ` Steve Dickson
2007-08-02 9:04 ` Stefan Walter
2007-08-03 2:40 ` Satyam Sharma
2007-08-03 14:51 ` Steve Dickson
2007-07-31 14:48 ` J. Bruce Fields
2007-07-31 14:48 ` J. Bruce Fields
2007-07-31 14:59 ` Jeff Layton
2007-08-02 7:55 ` Stefan Walter
2007-08-02 15:32 ` Jeff Layton
2007-08-02 15:32 ` [NFS] " Jeff Layton
2007-08-02 16:05 ` J. Bruce Fields
2007-08-02 16:05 ` [NFS] " J. Bruce Fields
2007-08-02 16:28 ` Jeff Layton
2007-08-02 16:28 ` [NFS] " Jeff Layton
2007-08-03 3:01 ` Neil Brown
2007-08-03 3:01 ` [NFS] " Neil Brown
2007-08-03 7:57 ` Stefan Walter
2007-08-03 7:57 ` [NFS] " Stefan Walter
2007-08-03 15:45 ` Jeff Layton
2007-08-03 16:07 ` J. Bruce Fields [this message]
2007-08-03 16:07 ` [NFS] " J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070803160709.GD456@fieldses.org \
--to=bfields@fieldses.org \
--cc=jlayton@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=nfs@lists.sourceforge.net \
--cc=stefan.walter@inf.ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.