nfsv4 server patches and status

[Trond Myklebust]

On Wed, 2007-07-11 at 10:47 +1000, Neil Brown wrote:
> 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 haven't bothered too much with volatile filehandles in the client
because recovery is always a problem and because there was never much
interest in supporting filesystems that use them. That said, I quite
agree that the pseudo filesystem is a special case that justifies their
use (and indeed that particular use was discussed just today in the v4.1
namespaces spec review).

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

Agreed: that should be fine for something like the pseudo filesystem.
I'm not sure I care about supporting the more general case of a
filesystem that wants to use volatile filehandles for regular files,
say.

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

I'd suggest just adding a field in the export options. This isn't likely
to be something you want to turn on and off on a per-superblock case.

Cheers
  Trond