Messages in this thread | | | Date | Fri, 3 Aug 2007 12:07:09 -0400 | Subject | Re: [NFS] rpc.mountd crashes when extensively using netgroups | From | "J. Bruce Fields" <> |
| |
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. - 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/
| |