[PATCH 0/5] Dynamic Pseudo Root

[J. Bruce Fields]

On Mon, Feb 18, 2008 at 10:49:14AM -0500, Trond Myklebust wrote:
> 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?

It does (or should do) a lazy unmount.  Can you see any problems with
that?

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

I agree that that's a problem.  It also seems unlikely in most setups,
and easy to solve in those clients (for the special case of filehandles
that are used only on mount).

The real advantage to the bind mount tricks is that they require no new
export interfaces, so they a) work (modulo the filehandle problems) on
old kernels, and b) allow postponing some harder decisions.

I suspect you're right that we'll eventually end up with a solution
that's mainly in-kernel.  I'll try to come up with some kind of rough
design next week.  That said....

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

... I was assuming it would be cleaner and more flexible to construct a
separate filesystem root for the psuedofilesystem.  What do you see as
the advantages of using the real fs with masked out dentries?

--b.