nfsv4 server patches and status

[Neil Brown]

On Tuesday July 10, bfields at fieldses.org wrote:
> On Tue, Jul 10, 2007 at 11:08:38AM -0400, Jeff Layton wrote:
> > I've been looking over this problem a bit and have a sparse few
> > brainstorming notes in the following RH BZ:
> > 
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237108
> > 
> > I've checked out Bryce's work above. I'm curious as to why he decided
> > to use a loopback mount here rather than something simple like tmpfs?
> > In some cursory checking, tmpfs seems to work fine when exported with a
> > fsid, and for this we know it would be exported with fsid=0.
> 
> It would be nice if we could use something like tmpfs instead.  Is there
> any way to get it to give out stable filehandles?  We could just declare
> the filehandles to be volatile, but I don't think clients deal well with
> volatile filehandles in practice.

If a client cannot handle volatile filehandles in the Server Pseudo
File System, then there is something very wrong, either with the
client or with the spec (I always felt the spec didn't take volatile
filehandles seriously, but maybe that has improved).

> 
> We don't really need to handle renames on the pseudofilesystem, so it'd
> be sufficient if it'd just give us the same filehandle as long as the
> path name stayed the same.

I'm fairly sure tmpfs will hand out stable filehandles that are stable
until a server reboot, and then with get new values that are again
stable until the next reboot.  That should be enough for any client
that can remember the path used to get to each volatile filehandle
(which Linux can with the dcache) - if the filehandle is FHEXPIRED,
relookup from the root.

I suspect we need a way for filesystems to tell nfsd that filehandles
are volatile...

NeilBrown