[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