[PATCH 0/5] Dynamic Pseudo Root

[J. Bruce Fields]

On Mon, Feb 18, 2008 at 01:25:02PM -0500, Trond Myklebust wrote:
> 
> On Mon, 2008-02-18 at 12:12 -0500, Steve Dickson wrote:
> > No reminder needed! :-) At this point, filehandles are hot being expired. 
> > From my testing, rebooting the server didn't seem to be a problem since the 
> > same filehandles were give out after the reboot. Especially when the fsid are
> > set.    
> 
> You can't rely on that, though. Yes, it might work if you reboot with no
> additional changes in /dev, initramfs, and all the other tmpfs
> filesystems that get started before NFS is started, but just something
> as innocuous as plugging in a usb drive before you reboot will mess that
> up.

We're using the fsid=0 convention to mark the pseudofilesystem, so the
problem is the part of the filehandle that identifies the inode, not the
part that identifies the filesystem.

If Steve hasn't seen the filehandle changing, it may be that tmpfs
assigns the same inode numbers to objects that are created in the same
order.

The solution (whether in the kernel or not) might be to use either a
real filesystem or a filesystem that constructs filehandles as a hash of
the pathname.

> Rebuilding your pseudo-filesystem after changing the export list will
> certainly screw things up quite royally.
> 
> > > IMO, the correct model for dealing with a pseudo-fs is the one that
> > > Brent described, in which you use the real fs as a base, but black out
> > > access to all non-directory dentries, and to all directory dentries that
> > > are not listed as being visible to the client by the export list.
> > Well this also carries the wait of pumping down the entire export list
> > to the kernel, which is something Bruce and I wanted to avoid since
> > thats a major change...
> 
> Are you and Bruce suggesting that changing all existing clients to match
> a new broken^Wless than perfect server model would be simpler?

No.  I want to fix that problem, but I'm not sure of the best way yet.
Apologies--I wish I was better at this.

> Doing upcalls to the mountd daemon is nothing new. We have a model for
> doing so, and for caching the results efficiently, so unless people
> start creating 100-path-component deep pseudo-filesystems then the
> overhead is unlikely to be a major performance killer.

You're imagining a "tell me the contents of this pseudofs directory"
upcall?  The current implementation limits the downcalls to a few K,
which would be awkward for directories with lots of entries (probably
not that unusual).  But that's probably fixable.

Sure, that might work.

--b.