[RFC,PATCH 0/4] Dynamic Pseudo Root

[Chuck Lever]

On Dec 7, 2007, at 5:23 PM, Steve Dickson wrote:
> J. Bruce Fields wrote:
>> On Fri, Dec 07, 2007 at 02:38:15PM -0500, Chuck Lever wrote:
>>>> The new '-R' command line argument, tells rpc.mountd to create a
>>>> pseudo root
>>>> if and only if, one is not already defined. Meaning if there is an
>>>> export entry in /etc/exports with an 'fsid=0' option, that entry
>>>> will be the pseudo root and rpc.mountd will not create a root.
>>> Why not make that the default behavior?
>>
>> Because it's experimental code for now.
>>
>>> Is there a case when you  need to switch this default behavior off?
>>> (ie, why have a command  line option to enable behavior that you  
>>> need
>>> to have anyway).
>>
>> I agree that the goal should eventually be to have it always on.
> ditto... The only concern I about having it always on is if there  
> is no
> v4 traffic, there is a lot of overhead for something that will not be
> used. But when v4 is the default, I think it will make more sense...
>
>
>>>> Now when a pseudo root is not defined, rpc.mountd will creates a
>>>> pseudo
>>>> root in '/var/lib/nfs/v4root'. By create I mean, the /var/lib/nfs/
>>>> v4root
>>>> directory will be created and then be mounted as a tmpfs  
>>>> filesystem:
>>>>
>>>>     mount -t tmpfs tmpfs /var/lib/nfs/v4root
>>>>
>>>> Making /var/lib/nfs/v4root a true mount point.
>>> What happens if there are more than one rpc.mountd processes running
>>> on the server?  Would having rpc.mound use a private namespace allow
>>> multiple instances to avoid colliding?
>>
>> We should keep rpc.mountd in a private namespace, and, yes, partly
>> because it will keep other processes (including other mountd's) from
>> stepping on each other's pseudo-filesystem.
> Yes.. Having rpc.mountd in a private namespace is the way to go if and
> only if we continue to implement pseudo roots in userspace.
>
> A concern I have with this implement, is how scalable it is? Do server
> export hundreds or even thousands of directories? I don't know...   
> If they do,
> then creating a mount point for each export probably will not scale  
> very well.
>
> So moving the implementation into the kernel, in the end, *might  
> be* a better
> solution, but at this point its an unknown... so until we do know,  
> I think
> this is a good first step...
>
> Question: How often are do people run multiple rpc.mountd daemons and
> for what reason?


I don't know the answer to that question, but the mount command has  
options to use different RPC versions and program numbers when  
contacting the mountd on an NFS server, ostensibly to allow server  
admins to provide unique NFS services on the same server.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com