[PATCH 0/5] Dynamic Pseudo Root

[J. Bruce Fields]

On Tue, Feb 19, 2008 at 09:47:16AM +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's one thing to require volatile filehandles for clients that want
some new feature (like the ability to access some filesystem type that
couldn't previously have been accessed without them), and it's another
to require volatile filehandle support for basic operation.

It might still be worth reconsidering whether volatile filehandles
should be in the spec.  But I seem to recall Sun people testing client
volatile filehandle support a few years ago, so it may not be true that
it's completely unimplemented.

Anyway, if we accept that requiring client volatile filehandle support
(even just in the case of mount) gives up too many clients, then the
only remaining argument is just that the problem would be rare, as it
requires a reexport to happen as a client is mounting.  That's a weak
argument on its own.  And especially if you have a lot of clients doing
automounting it seems likely to happen eventually, and seems unlikely
that the automounter could recover.

So, sorry, I guess we should give up on the idea that we can get away
with volatile filehandles.  Argh.

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

It would be pretty easy to advertise those filehandles as volatile, and
possibly to define some export interface that the filesystem could use
to advertise the quality of its filehandles.  The harder part may be
studying the exported filesystems and figuring out which need this
treatment?

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

Yes.  This is more complicated, as you have to deal with modifying a
preexisting filesystem instead of starting with a clean slate each time.
But maybe that's a solvable problem.

> 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'd rather not go that far.  Handling the odd a/b/c/d (with a and c in
the pseudofs) shouldn't require that.

> 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'll think harder about this and the directory-filtering approach.

There's one thing we could take from Steve's patches regardless: it
should be simple to just allow the administrator to tell mountd to treat
a given path as the export root.  An administrator that wanted v4
support would still have to do the kind of mount --bind setup they do
now, but at least they'd be able to get consistent v2/v3/v4 paths.
That's still just an interim solution, but it'd be an easy incremental
improvement over what we've got.

--b.