[PATCH 0/5] Dynamic Pseudo Root

[Trond Myklebust]

On Mon, 2008-02-18 at 13:56 -0500, J. Bruce Fields wrote:
> 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.

AFAICS, tmpfs just uses the default inode number assigned to it by
new_inode(). It sets the generation count using 'get_seconds()'. There
are no guarantees.

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

Most clients will just be doing LOOKUP when walking down the pseudo-fs,
in which case they will be looking up only one component.

Looking up more than one dentry only matters for the case of READDIR
calls and then only if the export list for this client happens to label
this directory as being a pseudo-filesystem entry. You can probably
invent a special optimisation for that case.