Re: [9fans] How to implement a moral equivalent of automounter

["Roman V. Shaposhnik" <rvs@sun.com>]

On Tue, 2008-12-02 at 13:18 -0500, erik quanstrom wrote:
> > I need to do in order to find out is:
> >   $ mount | fgrep /set/tools/gcc/4.0/intel-S2
> > and then I can manipulate my namespace even further to suit my needs.
>
> since nfs is always directly mounted, i think you are confusing
> direct mounts with things that are accessable because you have
> mounted a server which has mounted something else.

I don't think I'm confusing anything here. In fact, your statement
of "nfs is always directly mounted" seems to be quite confusing.
Here's how the above works (changing the names to protect the innocent):

  $ grep set /etc/auto_master
  +set.map
  $ ypcat -k set.map | grep
  /set/tools set.tools -rw,hard,intr,nosuid
  $ ypcat -k set.tools | grep gcc
  gcc -ro / gcc-stuff:/ /4.0 gcc-tools:/4.0 /4.1 gcc-tools:/4.1 /3.0 old-gcc-tools:/
  ....

The beauty of the last line is that it is a multi-mount and a lazy
multi-mount at that. Which means that:
  $ cd /set/tools/gcc/4.0
will mount gcc-tools:/4.0, but will not mount anything else.

Now, I actually omitted the replications part, which also
distributes the load between different servers when everybody
wants to use the latest gcc. And *then* knowing which server your
gcc actually came from could be a lifesaver.

> i would think that either you want encapsulation or you don't.
> see-through encapsulation would seem to me to be a contradiction
> in terms.

Thanks for the feedback. Lets see if you change your mind after the
explanation given above.

> if you don't, and you really need to know what's on the other
> end, you should mount it yourself.  /lib/namespace is a big
> help in this.

Sure, I can mount it myself. But the whole point is to have a
"lazy" mount that only gets mounted when I need it (and also
gets unmounted when I don't need it) AND also has nice things
like replications thrown in for a good measure.

It is kind of empowering to always have *everything* at your
fingertips, but only when you need it, so that it doesn't
clutter your setup. AND also be able to dig deeper into
things if they don't seem to work for some reason.

If the server that a shim filesystem made appear under /n/server
started to misbehave -- how would you know *what* is actually
misbehaving so that you can, perhaps, mount an alternative server
in its place?

Thanks,
Roman.