Re: [RFC] /proc/fs/nfsd/exports

G. Allen Morris III (gam3@dharma.sehda.com)
Fri, 30 Oct 1998 08:37:54 -0800

>>>Olaf Kirch said:
> On Thu, 29 Oct 1998 12:03:42 PST, "G. Allen Morris III" wrote:
> > I am adding a proc file to kernel nfsd to display the exports and would
>
> Great! That's one of the things I've always wanted to add because it
> facilitates stuff like 'exportfs -u' for e.g. exports to a netgroup.
> Otherwise you need to keep complicated export lists in memory. That's
> why the source for mountd and exportfs is so `amusing'.
>
> Speaking of mountd, it just occurred to me that it might as well
> be able to live without in-memory export lists at all. Consider the
> following:
>
> 1. mount request arrives from 1.2.3.4 for /home
> 2. try to obtain file handle from kernel for 1.2.3.4:/home.
> If successful, return file handle.
> 3. Check /var/lib/nfs/xtab for matching netmask, netgroup, or
> hostname wildcard matches. If no match is found, return error.
> Otherwise, add 1.2.3.4 + path name + options of best match to
> kernel export table.

If a match is found I suggest that the name of the match be used as the
client name. For example if a request comes in for 1.2.3.4 and
1.2.3.0/255.255.255.0 is in the xtab file then 1.2.3.4 would be added to
the list of IP #s for 1.2.3.0/255.255.255.0.

> 2. try to obtain file handle from kernel for 1.2.3.4:/home.
> If successful, return file handle. Otherwise, return error.
> The latter may happen if e.g. the export was for / but the
> kernel disallows sub-mounts.
>
> As to the format of the file, I would vote to make it compatible
> with the exports file. That makes it both human-readable, and gives
> you the parsing routines for free.
>

Yes I agree. The only question now is how to display the IP#s that each
client refers to.

Allen

---------------------------------
G. Allen Morris III

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/