nfsv4 server patches and status

[Jeff Layton]

On Tue, 10 Jul 2007 11:49:39 -0400
"J. Bruce Fields" <bfields at fieldses.org> wrote:

> On Tue, Jul 10, 2007 at 11:22:05AM -0400, Jeff Layton wrote:
> > The inode numbers would be stable for the life of the tmpfs filesystem,
> > but they could easily change on reboot (or if a dir was removed
> > and recreated).
> >
> > If that's unacceptable then tmpfs is probably not
> > usable for this, especially if we can't really use volatile fh's.
> > 
> > Back to pondering other options :-)
> 
> Well, maybe we could create an nfspseudofs that was a minor variant on
> tmpfs but that used something like a hash of the path name for the
> filehandle?
> 

I was actually thinking of something along those lines, and moving all
of this into the kernel:

(hand-wavy idea follows)

Have a nfspseudofs (that has no capability to make anything but
directories with some sort of semi-persistent inode numbers). This
filesystem could be disconnected from the main fs tree.


> Neil has also suggested using symlinks in the pseudofilesystem instead
> of bind mounts:
> 
> 	http://marc.info/?l=linux-nfs&m=117330705619509&w=2
> 

Neil has a good point in this. Using bind mounts may open things up for
hassles when a sysadmin wants to unmount. symlinks would be better in
this regard. We'd still need to do something to make sure that inode
numbers for the tmpfs dirs are unique though.

My other handwavy idea is to not build a new pseudo-root at all:

When a directory is exported, check to see if it's "disconnected". If
it is, backtrack dentries until we get to something that is exported
(or the root). Tag those inodes/dentries with a flag that indicates
that they are only to be used for LOOKUP calls. Fix up LOOKUP to
recognize a dir that has been tagged this way. Only do lookups in it
for entries that are valid exports or similarly tagged entries.

there may certainly be holes in that approach as well...

-- 
Jeff Layton <jlayton at redhat.com>