[PATCH 0/5] Dynamic Pseudo Root

[Trond Myklebust]

On Mon, 2008-02-18 at 12:12 -0500, Steve Dickson wrote:
> Trond Myklebust wrote:
> > On Mon, 2008-02-18 at 07:32 -0500, Steve Dickson wrote:
> >> Comments?
> > 
> > As I've stated before, I'm not at all comfortable about having the
> > mountd daemon screw around with bind mounts. AFAICS there will be issues
> > when you decide to change an export. For instance, what will happen if I
> > were to remove /home/tmp from the export list, but the umount fails
> > because the partition happens to be in use by the server?
> Well removing and adding exports on the fly have always been a bit
> iff... but I agree added another mount/umount to the scenario
> does not simply things... but on the other hand, once an export
> is removed from the list, both the kernel and rpc.mountd will no
> longer find it and fail the request as it does today. Once its
> out of the namespace... its out! Or am I missing something?
> 
> > 
> > Nor am I particularly happy about using a tmpfs model for the pseudo-fs:
> > that will lead to broken clients when the server reboots and the
> > filehandles expire. May I remind you that there are _no_ clients out
> > there with working code for dealing with recovering expired filehandles.
> 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.
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?

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.

Trond