From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <5fcd0595f4d5fbf6d4809a46a8078c79@vitanuova.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] tip o' the day
Date: Tue, 15 Feb 2005 15:29:00 +0000
From: rog@vitanuova.com
In-Reply-To: <2d1ac19c5e9bf73db861532bcc0c6168@crn.mteege.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 097a0ee0-ead0-11e9-9d60-3106f5b1d025

Matthias:
> > 	mntgen
> > 	srvfs plumbspace /n
> > 	plumber
> > 	rfork n
> > 	mount -b /srv/plumbspace /n
>
> I don't understand it completly.

here's some explanation:
	mntgen
		- creates mountpoints on demand in /n
	srvfs plumbspace /n
		- runs exportfs exporting /n on /srv/plumbspace
	plumber
		- runs the plumber; this runs in the same namespace as the exportfs
			command, so if a command run by the plumber changes its namespace,
			the namespace exported by exportfs will change too.
			(the "Local" rule allows this to happen on command).
	rfork n
		- fork the namespace
	mount -b /srv/plumbspace /n
		- take the namespace exported by exportfs and mount it on /n.
			this makes exportfs's namespace visible, but at one
			level of indirection - any changes to /n made by
			the plumber will now be visible to all. /srv/plumbspace could
			be deleted at this point.

> After that, I try
>
> % 9fs unixbox
> % ls /n/unixbox
>
> and get nothing. My profile looks like this

this is almost certainly because of a problem with exportfs (it
can't keep references to directories that have been walked to but
not opened).  the problem isn't easy to fix without a kernel interface
change, but mntgen has a recent workaround that fixes the problem.

copy mntgen from sources, and i think your problem should go
away.

  cheers,
    rog.