[PATCH 0/5] Dynamic Pseudo Root

[Steve Dickson]

Sorry for the delayed response...Dealing with a sick kid, among
other things... :-\

Neil Brown wrote:
> Some comments on the comments on this.....
> 
> 
> 1/ The use of volatile file handles as required by the use of tmpfs.
> 
>    Now I don't much care which way we go:  remove them from the spec
>    or implement them.  But refusing the allow them while they remain
>    in the spec just seems dishonest to me.
I have to agree with this. Just because nobody else can't support
something does not mean we should not... I bet if we started handling
out volatile filehandles and client started dropping, the support
would come pretty quickly... ;-)

> 
> 2/ We don't actually need to use TMPFS for the suggested
>    implementation.  We could use an ext2 filesystem loop-mounted on
>    some file, or even just part of the /var filesystem with
>    subtree_check set to avoid accessing other parts of the tree.
>    Then filehandles would be stable.
I agree. Trond's point of not being able to guarantee stable filehandles
is very valid, which is the main problem with the current design... 
but I'm not convinced using ext2 is the answer either.

> 
> 3/ It is quite possible to provide different name spaces to different
>    clients with the current approach, though the code doesn't quite
>    allow it (the kernel code is ready).
>    All lookups are done in the context of a client identifier, which
>    is roughly a string as it appears in /etc/exports (e.g. '*' or
>    '@mynetgroup' or '192.168.0.0/16').  There can be a different
>    virtual-root for each client.  So we could mount different trees
>    (Whether TMPFS or whatever) under
>          /var/lib/nfs/v4root/*/...
>          /var/lib/nfs/v4root/@mynetgroup/...
>          /var/lib/nfs/v4root/192.168.0.0!16/...
> 
>    and provide completely different name spaces for each.  There could
>    even be totally different from the name space seen by the server,
>    though the value of that would be questionable.
I guess I can see the advantage of different name space per client
but at this point I think it would be a complete nightmare managing 
multiple root trees... especially with the current technology, so
I see this as a next step and something we should keep in mind,
after we get the dynamic pseudo roots in place.   
 
> 
> 
> I think that there are probably issues here that we aren't really
> aware of, and doing some prototyping and experimentation is likely to
> be a good thing.
> So I would suggest going forward with the current approach in mountd
> and find out what *actual* problems it causes.  Then once we feel we
> genuinely understand the problem we can consider trialling a
> kernel-space implementation and see if it makes things better or
> worse.
I agree. We should be open to where this process takes us.. 
 
> 
> Steve:
>   2/ And what would you think of trying without tmpfs but just
>      creating real directories in /var and exporting them
>               ro,no_root_squash,subtree_check 
Yes I think this is next.... I start looking into it...

A few random comments about what has been said... 

I have to disagree with Trond (and a few other people I respect) that 
putting hooks into the lookup and readdir paths may not be the best 
approach for the Linux server implementation . It is a proven implementation
and we ultimately might end up there, but I just think we can come up
with a clearer and less invasive way of support dynamic pseudo roots.

Actual I like Gabriel's idea of using a pseudo-filesystem. Basically 
coming up very thin filesystem layer that its only job is to
give out *stable* filehandles may not be a bad idea... 

I think Trond is right, that the current up/down call  mechanism, with its 
caching, probably will scale so I think we can continue dynamically 
populate the kernels export cache, which much cleaner and less wasteful 
than pumping down all the exports (exports that may or may not be used).

So I guess I would like to see possibly some kernel support , definitely
user lever support that will keep all of the pseudo roots management
out of the main line server code...

steved.