[PATCH 0/5] Dynamic Pseudo Root

[Trond Myklebust]

On Tue, 2008-02-19 at 09:47 +1100, Neil Brown wrote:
> Some comments on the comments on this.....
> 
> 
> 1/ The use of volatile file handles as required by the use of tmpfs.
> 
>    If there are not multiple client implementations that support
>    volatile filehandles as described in the RFC, then such filehandles
>    MUST be struck from the RFC before it can be considered for
>    submission as a standard.  Not doing so would make a mockery of the
>    IETF process.
> 
>    Alternately, as long as the text remains in the RFC, it could be
>    seen as the duty of any server implementation to make genuine use
>    of volatile file handles so that client implementations can be
>    validated against it.  The "Pseudo root filesystem" seems to be an
>    obvious place for using volatile filehandles.

>    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.

It is irrelevant to consider what the spec says about an allowed feature
if the majority of clients don't support it. You can validate until the
cows come home, but it won't help make your server any more relevant to
the existing ecosystem.

>    I suspect that our NFS server doesn't currently flag TMPFS
>    filehandles as being volatile.  If it doesn't, it really should, no
>    matter what the outcome of the above.  ditto for FAT filehandles
>    and probably others.

Why? TMPFS files never survive a reboot anyway, and otherwise they are
quite stable for the duration of their lifetime.

The problem we have is matching TMPFS semantics to the semantics of a
pseudo-fs that demands changing.

> 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.

> 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.

Sure it is possible, but I can't see how this is a better solution, or
even are more scalable solution than just stuffing the required dentry
whitelist data into the existing exports cache.

AFAICS it just adds extra levels of complexity for no good reason.