[PATCH 0/5] Dynamic Pseudo Root

[J. Bruce Fields]

Not necessarily defending a side here, just trying to get the issues
written down:

On Mon, Feb 18, 2008 at 01:42:49PM -0500, Trond Myklebust wrote:
> On Mon, 2008-02-18 at 12:13 -0500, J. Bruce Fields wrote:
> > ... 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?
> 
>      1. The fact that it provides a stable basis for constructing
>         filehandles.

This can be dealt with by using a real filesystem, but of course that
does introduce the possibility that e.g. someone could mess with it or
it could otherwise become corrupted.  Neither our fault exactly, but we
shouldn't introduce new possibilities for failure if it's not necessary.

Another possibility might be a synthetic filesystem (let's call it
"pathfs") that computes filehandles using a hash of the path name.
(Presumably nobody cares much whether filehandles in the
pseudofilesystem are stable across renames.)  Of course that would give
up on the idea that the whole thing's possible without kernel changes.

Neither approach keeps filehandles from changing when previously
unexported paths become exported.  (Is that actually a requirement?)

>      2. No client changes.

Sure.  I give up on the idea that unstable filehandles will do for an
interim fix.

>      3. No mucking around with bind mounts and other namespace tricks
>         that can go wrong.

Go wrong in what way?  (Running up against resource limits, for
example?)

>      4. No races when the user decides to change the export table.
>         Instead of having to reconstruct a namespace after clearing the
>         in-kernel cache, mountd just sits there and continues to do its
>         usual thing.

If you're using the hypothetical "pathfs", you avoid such races by doing
as Steve's current code does: flush the export cache, lazy-unmount the
pseudofs, build a new one, and use that.

With a persistent filesystem you'd have to take some more care not to
touch paths unaffected by the export changes, which sounds annoying.

>      5. It works for more complex topologies too, such as the example
>         mentioned in section 7.3 of rfc3530: /a/b/c/d, where 'a' and 'c'
>         are pseudo-filesystems, whereas 'b' and 'd' are real.

Without addressing the question of whether it's actually a good idea,
you can actually accomplish #5 with a synthetic pseudofilesystem: create
it with all paths required to reach any export, then remount parts of it
onto real filesystems as necessary to bridge any gap.

A rough algorithm might be:
	Mount the pseudofilesystem at /pseudo.
	Also keep a copy of it: mount --bind /pseudo /copy
	For each exported path, mkdir /pseudo/path.
	For each exported path, in order from shortest to longest:
		If /pseudo/path exists, then just
			mount --bind /path /pseudo/path
		Otherwise, let "pa" be the longest prefix of path such
			that /pseudo/pa does exist, and
				mount --bind /copy/pa /pseudo/pa
			(so now /pseudo/path does exist), and then
				mount --bind /path /pseudo/path
	/copy is no longer needed: umount /copy.

--b.