[RFC,PATCH 0/4] Dynamic Pseudo Root

Trond Myklebust trond.myklebust at fys.uio.no
Fri Dec 7 19:18:39 EST 2007


On Fri, 2007-12-07 at 19:08 -0500, J. Bruce Fields wrote:
> On Fri, Dec 07, 2007 at 06:49:28PM -0500, Trond Myklebust wrote:
> > 
> > On Fri, 2007-12-07 at 14:57 -0800, Brent Callaghan wrote:
> > > This seems like a very complicated way to implement a pseudo root.
> > > 
> > > Why not implement it the same way as Solaris does it ?
> > > 
> > > When a Solaris NFSv4 server gets a PUTROOTFH it returns the client
> > > the real filehandle for the real system root.  In fact, all  
> > > filesystems that
> > > may provide a path to a real export are automatically exported, albeit
> > > with some simple restrictions:
> > > 	
> > > 	o LOOKUPs succeed only for path components that lead to
> > > 	   exported filesystems.
> > > 
> > > 	o READDIR shows only path components that lead to exported
> > > 	   filesystems.
> > > 
> > > The pseudo filesystem is the same as the real filesystem, with
> > > some restrictions.
> > 
> > Agreed. You are almost forced to do something like this if you want the
> > filehandles to remain valid when the administrator changes the export
> > options to allow access to path components that were previously part of
> > the pseudo-fs. Otherwise, you have to use volatile filehandles, which
> > are poorly supported by existing clients.
> 
> I agree.  On the other hand, this will normally only happen during the
> initial lookup of a mountpoint (on mount, or maybe on
> migration/failover).  Which I think is the simplest volatile-filehandle
> case for a client to handle.

I can easily construct situations where this is not the case. Imagine if
I export

/foo/bar

and the administrator on the NFSv4 client decides, for some reason or
another, to mount '/'. When I change the export to '/foo' or '/', then
the filehandle for 'foo', which is not a mountpoint on the client, may
change.

Cheers
  Trond



More information about the NFSv4 mailing list