[RFC,PATCH 0/4] Dynamic Pseudo Root

[Steve Dickson]

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? 

steved.