[PATCH 0/5] Dynamic Pseudo Root

[Neil Brown]

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.

   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.

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.


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.

Steve:
  1/ What would you think if inserting the client identifier in the
     path name used for the virtual root, thus potentially making lots
     of root trees?
  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 
     ??

Bruce:
   Are you interested in looking into flaging TMPFS filehandles as
   FH_VOLATILE ??

NeilBrown