[PATCH 0/5] Dynamic Pseudo Root

[Gabriel Barazer]

On 02/18/2008 9:09:32 PM +0100, Trond Myklebust 
<trond.myklebust at fys.uio.no> wrote:
> On Mon, 2008-02-18 at 20:41 +0100, Gabriel Barazer wrote:
> 
>> AFAIK, you can define only one pseudoroot fs for all the NFSv4 clients, 
>> so you have only one namespace to "export", right?
> 
> No! That would be a regression w.r.t. NFSv2/v3.

Maybe I used the wrong words: What I am trying to say is that you will 
not ever have one client (client1) seeing a /foo/bar export that is a 
different directory for another client. multiple namespaces would mean 
that they have independant export entries (=directories), and you could 
have a /foo entry exported on client1 that is a different directory than 
another "/foo" entry exported on client2. What we have is a "/foo" 
export which the same directory on every allowed client, but visible or 
not. This behavior is not a regression regarding NFSv2/3. I'm not 
talking about having one single "export" per client.

>> What we do with a 
>> real filesystem is creating directories and mount/binding them into a 
>> single directory defined as a pseudoroot fs. Having different 
>> permissions or visibility rules for the clients doesn't matter: you have 
>> to create all the mount/bind directories. For example:
>> /foo       client1
>> /bar	   client2
>>
>> You have to create "foo" and "bar" mounts into your pseudo root fs. The 
>> better part with a pseudo fs instead of a real one is that you don't 
>> have to manage all the directories and mount points by yourself since is 
>> it autogenerated, and you don't have to check the consistency 
>> (missing/removed mountpoints) of this pseudo root at startup (you have 
>> to with a real fs).
> 
> You are entirely missing the point of the pseudofs. Its main raison d'
> être is to act as a bridge between the legacy NFSv2/v3 namespace and the
> NFSv4 namespace. If a proposal can't tackle converting existing NFSv2/v3
> topologies, then it should go straight into the dustbin.

The proposed example can work with both NFSv2/3 and NFSv4 topologies. 
Let's clear this example as well:
exports:
/foo/bar       client1
/foo/bar/baz   client1, client2
/test          client3

the pseudo fs would contain:
/foo (or /foo/bar, depending on which directory has to be "mount --bind")
/test


The pseudo fs here acts as a (autogenerated) bridge between the two 
namespaces and the topology remains compatible with NFSv2/3.

Another thought: We could also use the nfsd filesystem to put the pseudo 
root inside a subdirectory, but with a different distinct "v4rootfs" 
filesystem, we can mount it anywhere, improving the flexibility while 
staying compatible with NFSv2/3

Sorry for the inaccuracies

(I also need to get some sleep, and seriously improve my English)

Gabriel