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.
