[9fans] How to implement a moral equivalent of automounter in Plan9?

[9fans] How to implement a moral equivalent of automounter in Plan9?

[Roman Shaposhnik]

Hi Guys!

I've been trying to implement a "lazy bind/mount" in Plan9 and it
dawned on
me that I don't really know any way of modifying calling process's
namespace
on-demand. In a automounter-like style.

Now, before you tell me that I shouldn't be doing it (well, may be I
shouldn't, but
please keep reading ;-)) let me give you a classical example of what
I'm after.

Consider a way /net is set up on Solaris as an automounter map. Anytime
there's any access requesting /net/<machine name>/<nfs exports>/files...
the namespace of the calling process gets modified because of the
automounter issuing an NFS mount.

Now, if I want the moral equivalent of the above to happen every time
I access /n/sources/plan9/sys/src/cmd/cpu.c on Plan9 I can have a
synthetic fileserver mounted on /n/ and doing the right thing. But that
will not make the following entry be added to my namespace:
     mount '#s/sources' /n/sources

So, the question is: am I missing something really obvious here,
or is writing a kernel driver that really does modify a namespace the
only way to go here?

Thanks,
Roman.

[9fans] How to implement a moral equivalent of automounter in Plan9?

[Fco. J. Ballesteros]

That's what bns does on Plan B.
AFAIK, there's no way on Plan 9 to automate mounts making
everythiing work after the FS goes away.

Probably you could grab just bns and adsrv (the registry) from Plan B
and runt hem on plan 9 as they are.

>  From: rvs@sun.com
>  To: 9fans@9fans.net
>  Reply-To: 9fans@9fans.net
>  Date: Mon Dec  1 08:26:23 CET 2008
>  Subject: [9fans] How to implement a moral equivalent of automounter in Plan9?
>
>  Hi Guys!
>
>  I've been trying to implement a "lazy bind/mount" in Plan9 and it
>  dawned on
>  me that I don't really know any way of modifying calling process's
>  namespace
>  on-demand. In a automounter-like style.
>
>  Now, before you tell me that I shouldn't be doing it (well, may be I
>  shouldn't, but
>  please keep reading ;-)) let me give you a classical example of what
>  I'm after.
>
>  Consider a way /net is set up on Solaris as an automounter map. Anytime
>  there's any access requesting /net/<machine name>/<nfs exports>/files...
>  the namespace of the calling process gets modified because of the
>  automounter issuing an NFS mount.
>
>  Now, if I want the moral equivalent of the above to happen every time
>  I access /n/sources/plan9/sys/src/cmd/cpu.c on Plan9 I can have a
>  synthetic fileserver mounted on /n/ and doing the right thing. But that
>  will not make the following entry be added to my namespace:
>   mount '#s/sources' /n/sources
>
>  So, the question is: am I missing something really obvious here,
>  or is writing a kernel driver that really does modify a namespace the
>  only way to go here?
>
>  Thanks,
>  Roman.

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

[erik quanstrom]

> That's what bns does on Plan B.
> AFAIK, there's no way on Plan 9 to automate mounts making
> everythiing work after the FS goes away.
>

aan?

- erik

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

[Francisco J Ballesteros]

bns != aan

On Mon, Dec 1, 2008 at 3:34 PM, erik quanstrom <quanstro@coraid.com> wrote:
>> That's what bns does on Plan B.
>> AFAIK, there's no way on Plan 9 to automate mounts making
>> everythiing work after the FS goes away.
>>
>
> aan?
>
> - erik
>
>

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

[erik quanstrom]

> bns != aan
>
> On Mon, Dec 1, 2008 at 3:34 PM, erik quanstrom <quanstro@coraid.com> wrote:
> >> That's what bns does on Plan B.
> >> AFAIK, there's no way on Plan 9 to automate mounts making
> >> everythiing work after the FS goes away.
> >>
> >
> > aan?

well, sure.  i wasn't saying that they are the same.

i understood your claim to be that
plan 9 has no way of automaticly remounting a fs.
aan does automaticly remount.

- erik

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

[Francisco J Ballesteros]

Maybe I missunderstood.
I mean that unless the server is reached in exaclty the same way
(which, in general, if you want something like automount, it does not)
aan is not enough.
It's fine to reach the same FS on the same address when the net goes
and come, but otherwise it is not IIRC.

On Mon, Dec 1, 2008 at 4:08 PM, erik quanstrom <quanstro@coraid.com> wrote:
>> bns != aan
>>
>> On Mon, Dec 1, 2008 at 3:34 PM, erik quanstrom <quanstro@coraid.com> wrote:
>> >> That's what bns does on Plan B.
>> >> AFAIK, there's no way on Plan 9 to automate mounts making
>> >> everythiing work after the FS goes away.
>> >>
>> >
>> > aan?
>
> well, sure.  i wasn't saying that they are the same.
>
> i understood your claim to be that
> plan 9 has no way of automaticly remounting a fs.
> aan does automaticly remount.
>
> - erik
>
>

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

[Russ Cox]

The automounter is symptomatic of an ill that Plan 9 has cured.
Since adding to the name space requires no special privileges,
ordinary users can mount the servers they want to use directly,
instead of needing a privileged daemon to guess their intent and
mount servers on demand.  In Plan 9, scripts that care to use
a particular server simply put "9fs server" in their script.

One could write a user-level server that interposes on exportfs,
and if it sees a failed walk of "name" in the root, runs "9fs name"
and resends the walk, but that could only work for a single user:
in general, mounting requires authentication, so hiding the mounting
requires hiding the authentication.  This is easy if you're only worried
about one user--just use that user's factotum--but not really possible
when there are multiple users involved.  In that case, automatic
mounting takes control of authentication away from the users.

Russ

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

[ron minnich]

On Mon, Dec 1, 2008 at 9:48 AM, Russ Cox <rsc@swtch.com> wrote:
> The automounter is symptomatic of an ill that Plan 9 has cured.
> Since adding to the name space requires no special privileges,
> ordinary users can mount the servers they want to use directly,

The other reason for an automounter was the observed unreliability of
nfs servers. The automounter reduced the phone calls sysads got about
"what is this NFS server that's not responding, why am I still trying,
since I don't even use it?" The goal was to aggressively unmount
whenever possible, so as to minimize the vulneratbility of desktops to
unreliable servers.

But this need for an automounter has not really existed for probably
17 years or so ... NFS servers are pretty reliable in many cases. It
is interesting to see the use case for automoiuters change.

Now I could swear that about 5 years ago somebody posted an
automounter for plan 9 on this list. It was tiny.

ron

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

[Roman V. Shaposhnik]

On Mon, 2008-12-01 at 10:17 -0800, ron minnich wrote:
> But this need for an automounter has not really existed for probably
> 17 years or so ... NFS servers are pretty reliable in many cases. It
> is interesting to see the use case for automoiuters change.

Right. I'm actually too young to be able to witness that original
use case. My personal affection for automounter comes from the
fact that it makes things "lazy" for me. And that property has
applications starting from /media/floppy all the way to not
explicitly mounting 200000 individual NFS servers, yet being
able to always get each and every one of them by simply doing
cd /net/<machine name>.

In Plan9 land you don't need automounter to deal with
/media/floppy. But cd /net/<machine name> is not there.
At least not by default.

Thanks,
Roman.

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

[Dan Cross]

On Mon, Dec 1, 2008 at 1:31 PM, Roman V. Shaposhnik <rvs@sun.com> wrote:
> In Plan9 land you don't need automounter to deal with
> /media/floppy. But cd /net/<machine name> is not there.
> At least not by default.

I see what you're after.  If that's all you want, though, I have to
confess I don't see how it would be too hard to implement.  You could
just write a shim filesystem that would sit on top of /net and monitor
walk's and handle importing and mounting for you.  If you followed a
simple convention of always referring to a filesystem as, say,
'/a/<machine>' then it wouldn't require any configuration at all.
Hell, you could probably even implement it as a shell script.

What's not there, aside from the program itself, of course?

        - Dan C.

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

[Roman V. Shaposhnik]

On Mon, 2008-12-01 at 16:18 -0500, Dan Cross wrote:
> On Mon, Dec 1, 2008 at 1:31 PM, Roman V. Shaposhnik <rvs@sun.com> wrote:
> > In Plan9 land you don't need automounter to deal with
> > /media/floppy. But cd /net/<machine name> is not there.
> > At least not by default.
>
> I see what you're after.  If that's all you want, though, I have to
> confess I don't see how it would be too hard to implement.  You could
> just write a shim filesystem that would sit on top of /net and monitor
> walk's and handle importing and mounting for you.  If you followed a
> simple convention of always referring to a filesystem as, say,
> '/a/<machine>' then it wouldn't require any configuration at all.
> Hell, you could probably even implement it as a shell script.
>
> What's not there, aside from the program itself, of course?

I totally agree that a shim filesystem whould solve an immediate issues
perfectly. The solution, however, will be a 'black box'. If I mount
such a filesystem under /n/ all I would see in my name space is a single
mount. Everything that goes on underneath /n/<name>/stuff... will be
completely hidden from me inside the namespace of the shim fileserver
itself.

I'm not sure whether it is an artifact of me spending lots of time under
Solaris inside a pretty well managed Sun's intranet, but I do appreciate
the fact that every time I access something like:
   /set/tools/gcc/4.0/intel-S2
I actually have a total transparency of where this thing came from. All
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.

Now, the only [meta]question I have lest for this list at this point is:
am I unique in appreciating something like the above? Do you think I'd
better off with a shim-like approach instead (where /set would be
managed 100% by a single fileserver hiding all the details from me)?

Thanks,
Roman.

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

[erik quanstrom]

> I totally agree that a shim filesystem whould solve an immediate issues
> perfectly. The solution, however, will be a 'black box'. If I mount
> such a filesystem under /n/ all I would see in my name space is a single
> mount. Everything that goes on underneath /n/<name>/stuff... will be
> completely hidden from me inside the namespace of the shim fileserver
> itself.

that's the point.

> 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 would think that either you want encapsulation or you don't.
see-through encapsulation would seem to me to be a contradiction
in terms.

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.

if you do, then you don't want to care what's over there.

- erik

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

[Roman V. Shaposhnik]

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.

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

[erik quanstrom]

>> 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:/

but the machine you're logged into does do the mount directly
in your namespace.  (the one and only namespace.)  conversely,
with srvfs, you are mounting a fs that inturn mounts other fs.
fundamentally this is different.

(hey, could you imagine a seperate nfs mount for ken's compiler?
laughable, no?)

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

nope.  sorry.  i would hate to see such a botch in plan 9.
if you want to distribute load by having multiple fs, then
it should be done so that the client wouldn't know or care
that any distribution is going on.

- erik

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

[hiro]

> (hey, could you imagine a seperate nfs mount for ken's compiler?
> laughable, no?)

It would make a lot more sense than an nfs mount for some gcc tools.

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

[Roman V. Shaposhnik]

On Tue, 2008-12-02 at 14:29 -0500, erik quanstrom wrote:
> >> 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.
>
> nope.  sorry.  i would hate to see such a botch in plan 9.
> if you want to distribute load by having multiple fs, then
> it should be done so that the client wouldn't know or care
> that any distribution is going on.

I think you're deliberately exaggerating here. You must
know full well, that the client is *not* affected by that
knowledge when everything works as expected(*), which would
be in 99% of the cases (at lest here within Sun's intranet).
And the fact that this knowledge can be easily obtained makes
that 1% bearable.

That said, thanks for the feedback anyway. I consider this
thread closed expect for that one question I asked Russ.

Thanks,
Roman.

P.S. I've seen this disbelief in the fact that automoter + NFS
actually can be really convenient mostly come from Linux people.
Which is not surprising given how crappy autofs and NFS are
implemented there.

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

[erik quanstrom]

> > nope.  sorry.  i would hate to see such a botch in plan 9.
> > if you want to distribute load by having multiple fs, then
> > it should be done so that the client wouldn't know or care
> > that any distribution is going on.
>
> I think you're deliberately exaggerating here. You must
> know full well, that the client is *not* affected by that
> knowledge when everything works as expected(*), which would
> be in 99% of the cases (at lest here within Sun's intranet).
> And the fact that this knowledge can be easily obtained makes
> that 1% bearable.

are you saying that clients don't need information about the
variety of nfs servers serving the xyz tree?  if they do not, then
could you explain how the client picks which server to mount.

- erik

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

[Roman V. Shaposhnik]

On Tue, 2008-12-02 at 16:35 -0500, erik quanstrom wrote:
> > > nope.  sorry.  i would hate to see such a botch in plan 9.
> > > if you want to distribute load by having multiple fs, then
> > > it should be done so that the client wouldn't know or care
> > > that any distribution is going on.
> >
> > I think you're deliberately exaggerating here. You must
> > know full well, that the client is *not* affected by that
> > knowledge when everything works as expected(*), which would
> > be in 99% of the cases (at lest here within Sun's intranet).
> > And the fact that this knowledge can be easily obtained makes
> > that 1% bearable.
>
> are you saying that clients don't need information about the
> variety of nfs servers serving the xyz tree?  if they do not, then
> could you explain how the client picks which server to mount.

The client does not pick. It is part of the automounter's decision.
And once the server gets picked by the automounter, it is awfully
convenient that you see the actual mount as part of the namespace.

Thanks,
Roman.

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

[Dan Cross]

On Tue, Dec 2, 2008 at 8:26 PM, Roman V. Shaposhnik <rvs@sun.com> wrote:
> The client does not pick. It is part of the automounter's decision.
> And once the server gets picked by the automounter, it is awfully
> convenient that you see the actual mount as part of the namespace.

Folks are talking at cross-purposes here; I think it's a semantics
issue more than anything.

In Plan 9, the automounter would be considered part of the client.  In
plan 9, the canonical way to implement an automounter would be with a
filesystem that did it on your behalf; the smarts for all the
replication and so on would be put there.  The namespace would be
visible by asking the automounter (which in this environment is
probably a filesystem) what the namespace is.

There's nothing in the environment that prevents it from being
implemented other than time and inclination.

        - Dan C.

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

[erik quanstrom]

> > are you saying that clients don't need information about the
> > variety of nfs servers serving the xyz tree?  if they do not, then
> > could you explain how the client picks which server to mount.
>
> The client does not pick. It is part of the automounter's decision.
> And once the server gets picked by the automounter, it is awfully
> convenient that you see the actual mount as part of the namespace.

there is the rub.  for the "actual mounts" to be meaningful on the client,
they need to be interpreted on the client.

in the case of srvfs, the namespace is interpreted on the server running
srvfs.  (srvfs is a proxy.)  in fact, you might not be able to directly mount
the stuff srvfs serves.  i use it (actually exportfs) every day to export il-only
fileservers via aan over tls over the internet.

one part of the ns making up the namespace i import is #s/boot.
if that were interpreted on the client, it would point to a different
fs (in a different authentication domain) than it does on the server.

- erik

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

[Dave Eckhardt]

> P.S. I've seen this disbelief in the fact that automoter + NFS
> actually can be really convenient mostly come from Linux people.

Perspective depends on experience.

AFS has its warts, but, trust me, if you've used it for a while,
you will not find yourself excitedly perusing the volume location
database to see where your bits are coming from.  In fact, you
generally will not notice when your volume moves from one server
to another, even if you are reading from and writing to it at
the time.

Dave Eckhardt

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

[Steve Simon]

> AFS has its warts, but, trust me, if you've used it for a while,
> you will not find yourself excitedly perusing the volume location
> database to see where your bits are coming from.

Is there an AFS client for plan9 anywhere?

Just curious.

-Steve

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

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

On Thu, Dec 04, 2008 at 02:58:15PM +0000, Steve Simon wrote:
> > AFS has its warts, but, trust me, if you've used it for a while,
> > you will not find yourself excitedly perusing the volume location
> > database to see where your bits are coming from.  
> 
> Is there an AFS client for plan9 anywhere?

AFAIK no.  There's a long list of things that would have to happen before
this was feasable, not the least of which is to get factotum speaking
Kerberos (V5, and the 5to4 wedge... sigh).  It might be possible to bring
the RxRPC libraries over without too much pain.  And that's just getting
started.

You can sort of, ish, emulate AFS on Plan 9 by having a UNIX box running an
AFS client and your Kerberos credentials and then importing /afs via SSH.
Crude hack, but works.

It might be an interesting project for some student(s) to reimplement
Kerberos 5 for Plan 9... it's something of an open question of just how
minimal and tasteful the implementation can be when it's not MIT code. ;)

--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

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

[Steve Simon]

> It might be an interesting project for some student(s) to reimplement
> Kerberos 5 for Plan 9... it's something of an open question of just how
> minimal and tasteful the implementation can be when it's not MIT code. ;)

Indeed, if anyone ever does look at it, can I vote for including
the hooks for MicroSoft's extensions?

-Steve

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

[Roman V. Shaposhnik]

On Thu, 2008-12-04 at 02:39 -0500, Dave Eckhardt wrote:
> > P.S. I've seen this disbelief in the fact that automoter + NFS
> > actually can be really convenient mostly come from Linux people.
>
> Perspective depends on experience.
>
> AFS has its warts, but, trust me, if you've used it for a while,
> you will not find yourself excitedly perusing the volume location
> database to see where your bits are coming from.  In fact, you
> generally will not notice when your volume moves from one server
> to another, even if you are reading from and writing to it at
> the time.

This is an interesting point. At some distant point in the past
(last century, actually) I was drawn to AFS because of the features,
but left in horror because of the complexity.

I guess it doesn't really matter if your environment is being managed
by a good IT -- you just reap the benefits. But as a tinkerer,
I wouldn't call AFS malleable.

Thanks,
Roman.

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

[Dave Eckhardt]

> At some distant point in the past (last century, actually)
> I was drawn to AFS because of the features, but left in
> horror because of the complexity.

The goal was adding an enterprise-scale distributed file
system to an existing operating system (Unix), where
"enterprise-scale" meant 5,000 users (the first prototype
supported 400 users on 120 workstations in 1984; this
evening CMU's AFS cell hosts 30,821 user volumes, roughly
half a gigabyte each; there are cells with more users and
cells with more bits.

It may be the case that 25 years later NFSv4 solves all the
same problems with greater elegance--which would be good,
because civilization should advance, and it really is useful
for a community of 30k people to seamlessly share files.

> I guess it doesn't really matter if your environment is
> being managed by a good IT -- you just reap the benefits.
> But as a tinkerer, I wouldn't call AFS malleable.

A 747 isn't as malleable as an ultralight.  If you can
figure out how to carry several hundred people across an
ocean in something as easy to build and maintain as an
ultralight, people will most definitely take notice.  And
such a thing could be the case for distributed file systems.

Dave Eckhardt

P.S. Here's some rationale behind the horrific complexity:
  http://www.cs.cmu.edu/~satya/docdir/p35-satyanarayanan.pdf

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

[erik quanstrom]

On Thu Dec  4 23:37:02 EST 2008, davide+p9@cs.cmu.edu wrote:
> supported 400 users on 120 workstations in 1984; this
> evening CMU's AFS cell hosts 30,821 user volumes, roughly
> half a gigabyte each; there are cells with more users and
> cells with more bits.

31000/2 is about 15tb.  that seems pretty reasonable these days.
do you know what the peak throughput is?

- erik

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

[Roman Shaposhnik]

On Dec 4, 2008, at 8:43 PM, erik quanstrom wrote:
> On Thu Dec  4 23:37:02 EST 2008, davide+p9@cs.cmu.edu wrote:
>> supported 400 users on 120 workstations in 1984; this
>> evening CMU's AFS cell hosts 30,821 user volumes, roughly
>> half a gigabyte each; there are cells with more users and
>> cells with more bits.
>
> 31000/2 is about 15tb.  that seems pretty reasonable these days.
> do you know what the peak throughput is?

Good point.

Btw, what's the typical size for the coraid deployment?

Thanks,
Roman.

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

[erik quanstrom]

>> 31000/2 is about 15tb.  that seems pretty reasonable these days.
>> do you know what the peak throughput is?
>
> Good point.
>
> Btw, what's the typical size for the coraid deployment?

we see everything from 1tb to 2400tb.
our most popular appliance, the sr2421,
holds 24 disks.

- erik

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

[Roman Shaposhnik]

On Dec 4, 2008, at 8:35 PM, Dave Eckhardt wrote:
>> At some distant point in the past (last century, actually)
>> I was drawn to AFS because of the features, but left in
>> horror because of the complexity.
>
> The goal was adding an enterprise-scale distributed file
> system to an existing operating system (Unix), where
> "enterprise-scale" meant 5,000 users (the first prototype
> supported 400 users on 120 workstations in 1984; this
> evening CMU's AFS cell hosts 30,821 user volumes, roughly
> half a gigabyte each; there are cells with more users and
> cells with more bits.

Fair enough. But what's the adoption overall? You see,
as with any enterprise application there's a very delicate
balance to be had -- err on the side of oversimplification
and you can't deliver, err on the side of complexity and
you loose to the solutions which are "good enough".

>> I guess it doesn't really matter if your environment is
>> being managed by a good IT -- you just reap the benefits.
>> But as a tinkerer, I wouldn't call AFS malleable.
>
> A 747 isn't as malleable as an ultralight.  If you can
> figure out how to carry several hundred people across an
> ocean in something as easy to build and maintain as an
> ultralight, people will most definitely take notice.  And
> such a thing could be the case for distributed file systems.

See, that's the problem with complex systems -- they try
too hard to solve a problem with a set of requirements that
change faster than the implementations can adapt.

I see a lot of that in C++ (how many times was the latest
standard delayed?, how long did it take compiler vendors
to get template template parameters right? etc.) and other
things which were meant to be "enterprise grade".

To some extent, the popularity of NFS (is there any NAS box
that talks AFS?) and Linux is one big testament to the
power of "good enough" or "worse is better".

Designing "enterprise grade" things is very hard work.
Implementing them is even harder. The good news
is that it pays well. The bad news is that you have to
be really brave to withstand the fear of being obsolete
by changing requirements.

> P.S. Here's some rationale behind the horrific complexity:
>  http://www.cs.cmu.edu/~satya/docdir/p35-satyanarayanan.pdf

Interesting paper! Thanks for providing a pointer to it.

Thanks,
Roman.

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

[erik quanstrom]

> To some extent, the popularity of NFS (is there any NAS box
> that talks AFS?) and Linux is one big testament to the
> power of "good enough" or "worse is better".

i really hate this meme.  it doesn't mean anything.

imho, the reasons nfs is popular are mostly political and
logistical rather than technical.  sun pushed nfs,
and in the days when nfs became popular, it was
difficult to add a fs to your closed-source, no compiler
operating system.  so saying calling nfs an example of
"worse is better" implies that using nfs is a technical
decision.  i don't think that it is.

even in the cannonical usage, "worse is better" is
a parody of the idea that complexity is expensive and
adding complexity  needs to be motivated by a
real problem and a real solution.  i believe rob
said (but can't find a reference)
	fancy algorithms are slow when n is small.
	n is usually small.

the opposing  idea, "better is better" of course is
tautology.  unless you use bill clintonesque definitions.
so perhaps we should call this the "bill clinton"
philosophy.

- erik

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

[Roman Shaposhnik]

On Dec 6, 2008, at 6:27 AM, erik quanstrom wrote:
>> To some extent, the popularity of NFS (is there any NAS box
>> that talks AFS?) and Linux is one big testament to the
>> power of "good enough" or "worse is better".
>
> i really hate this meme.  it doesn't mean anything.

It depends on the point of view, I guess. To me its value
is about juxtaposing two approaches to the design.
Being a non-native English speaker the wording and
metaphors don't bother me that much. Three essays
helped me understand why software produced by
different "schools of thought" is so drastically different:
    * Worse is better:
        http://www.jwz.org/doc/worse-is-better.html
    * On the fact that Atlantic Ocean has two sides:
        http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD611.html
    * On the fact that most software  is written on one side of the
Atlantic:
       http://www.youtube.com/watch?v=s7ROTJKkhuI

> imho, the reasons nfs is popular are mostly political

Oh, come on! ;-) You sound like Bjarne now, complaining
that James Gosling, hijacked OOP with tons of corporate
support (which is somewhat true) and that people don't
want to use C++ because Sun brainwashed them, not
because it is the most convoluted language after ALGOL 68.

> and logistical rather than technical.  sun pushed nfs,

That is true. But without  NetAPP and others, that wouldn't be
possible.

> so saying calling nfs an example of "worse is better" implies
> that using nfs is a technical decision.

You seem to be interpreting worse-is-better quite differently
from how I interpret it. To me it is all about reasoning about survival
skills. And yes, I tend to agree with its main premise, that mediocracy
usually has better survival skills. Nothing to do with technical
aspects.

Thanks,
Roman.

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

[erik quanstrom]

On Sat Dec  6 19:05:07 EST 2008, rvs@sun.com wrote:
> Oh, come on! ;-) You sound like Bjarne now, complaining
> that James Gosling, hijacked OOP with tons of corporate

i don't recall having written a competitor to nfs.

> And yes, I tend to agree with its main premise, that mediocracy
> usually has better survival skills. Nothing to do with technical
> aspects.

better (by definition) is always better.  however, if you spend resources
making something better and no one can tell the difference,
or no one cares, then it is not better.

- erik

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

[Rob Pike]

i don't understand this thread.  the "moral" equivalent? surely you
mean "functional" or "rough" or "approximate" or some other adjective,
not "moral".  the phrase "moral equivalent" originates in the "moral
equivalent of war".  using it in this context is wrong, misguided,
maybe punishable.

the only moral thing about the automounter is that it's not running on
this here machine.  life is imperfect and morality is weaker on other
machines i use.

-rob

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

[akumar]

...
> surely you mean "functional" or "rough" or "approximate" or some other
> adjective, not "moral".
...
> -rob

Another adjective would make the topic of discussion too specific,
before ever entering the discussion. But without any adjective, the
topic is too obviously incomplete.

;)
akumar

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

[Roman Shaposhnik]

On Dec 6, 2008, at 9:20 PM, Rob Pike wrote:
> i don't understand this thread.  the "moral" equivalent? surely you
> mean "functional" or "rough" or "approximate" or some other adjective,
> not "moral".

Isn't "moral equivalent of an X" an idiomatic expression that goes
beyond
the original use of it in James's essay?

> the phrase "moral equivalent" originates in the "moral
> equivalent of war".  using it in this context is wrong, misguided,
> maybe punishable.

Huh? If this is a joke -- its not funny. The fact that I speak with an
accent (even in writing) doesn't mean I think with an accent.

> the only moral thing about the automounter is that it's not running on
> this here machine.  life is imperfect and morality is weaker on other
> machines i use.


What is the point of this paragraph?

Thanks,
Roman.

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

[Noah Evans]

To clarify Rob's point, the phrase "moral equivalence" comes with some
pretty hefty baggage. In modern usage it's primarily a right wing
term, used to derogatorily refer to leftist arguments. "Morally
equivalent" arguments typically assert that pro-western groups have
selfish(typically economic) motivations when acting(e.g. the wars in
Vietnam and Iraq).

Does that help?

Noah



On Sat, Dec 6, 2008 at 11:53 PM, Roman Shaposhnik <rvs@sun.com> wrote:
> On Dec 6, 2008, at 9:20 PM, Rob Pike wrote:
>>
>> i don't understand this thread.  the "moral" equivalent? surely you
>> mean "functional" or "rough" or "approximate" or some other adjective,
>> not "moral".
>
> Isn't "moral equivalent of an X" an idiomatic expression that goes beyond
> the original use of it in James's essay?
>
>> the phrase "moral equivalent" originates in the "moral
>> equivalent of war".  using it in this context is wrong, misguided,
>> maybe punishable.
>
> Huh? If this is a joke -- its not funny. The fact that I speak with an
> accent (even in writing) doesn't mean I think with an accent.
>
>> the only moral thing about the automounter is that it's not running on
>> this here machine.  life is imperfect and morality is weaker on other
>> machines i use.
>
>
> What is the point of this paragraph?
>
> Thanks,
> Roman.
>
>

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

[Roman V. Shaposhnik]

On Mon, 2008-12-01 at 09:48 -0800, Russ Cox wrote:
> The automounter is symptomatic of an ill that Plan 9 has cured.
> Since adding to the name space requires no special privileges,
> ordinary users can mount the servers they want to use directly,
> instead of needing a privileged daemon to guess their intent and
> mount servers on demand.  In Plan 9, scripts that care to use
> a particular server simply put "9fs server" in their script.

Russ, could, you please be a tad more specific as to what ill
exactly are you referring to?

While I agree that Plan9 completely removes the need for
automounter to be a privileged application, I still don't
see an easy way (expect may be bns and adsrv) to have that
other property of automounter being easily implemented
within Plan9 framework.

The property I'm talking about is the ability of an external
program to manage my namespace for me. Perhaps in response
to some of my actions, or simply based on some set of rules.

> One could write a user-level server that interposes on exportfs,
> and if it sees a failed walk of "name" in the root, runs "9fs name"
> and resends the walk,

That's very similar to what I referred to as a "synthetic filesystem
doing the right stuff". But as I pointed out in my original email
this approach has a downside of never exporting these mounts
into the namespace of the process that caused them.

> but that could only work for a single user:
> in general, mounting requires authentication, so hiding the mounting
> requires hiding the authentication.  This is easy if you're only worried
> about one user--just use that user's factotum--but not really possible
> when there are multiple users involved.  In that case, automatic
> mounting takes control of authentication away from the users.

I guess I'm not quite following you here. What I'm talking about is
a per-process modifications of namespace by some external agent
(be it kernel driver or userspace application). As such it is not
at all different from a user issuing something like "9fs name"
directly.

Could you, please, elaborate what exact multi-user scenario do you
have in mind?

Thanks,
Roman.

P.S. I have always wanted to be able to trade namespaces
between different processes the same way file descriptors get
traded using #s. On the other hand, I have never ever possessed
enough insight into the overall ramification of such idea
to really judge it as good or bad. If others have thought about
the same thing -- I would appreciate the feedback.

Now off to take a look at bns and adsrv...

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

[Bakul Shah]

On Mon, 01 Dec 2008 10:25:09 PST "Roman V. Shaposhnik" <rvs@sun.com>  wrote:
>
> P.S. I have always wanted to be able to trade namespaces
> between different processes the same way file descriptors get
> traded using #s. On the other hand, I have never ever possessed
> enough insight into the overall ramification of such idea
> to really judge it as good or bad. If others have thought about
> the same thing -- I would appreciate the feedback.

There is something appealing about being able to package up
some resources in a namespace and then copying or moving the
whole thing to another process, possibly on another node. The
recipient doesn't have to know how it was put together or be
able to modify the namespace structure.

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

[geoff]

Won't srvfs (see exportfs(4)) do what you want (packaging up a
namespace)?

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

[Roman V. Shaposhnik]

On Mon, 2008-12-01 at 18:11 -0500, geoff@plan9.bell-labs.com wrote:
> Won't srvfs (see exportfs(4)) do what you want (packaging up a
> namespace)?

It will. But in a read-only, black-box way. My problem is that
I don't see how I can even inspect the namespace that it exports,
let alone manipulate it.

Now, I've asked the manipulation question in my reply to Russ,
so if you're interested in pursuing this topic -- lets do it
in that other part of the thread.

Thanks,
Roman.

P.S. Don't get me wrong though: srvfs is a very useful tool, its
just that I'm asking a bit broader question than what it was designed
to answer.

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

[Russ Cox]

> Russ, could, you please be a tad more specific as to what ill
> exactly are you referring to?

I was referring to needing special privilege to mount something.

> While I agree that Plan9 completely removes the need for
> automounter to be a privileged application, I still don't
> see an easy way (expect may be bns and adsrv) to have that
> other property of automounter being easily implemented
> within Plan9 framework.

I described a simple shim program (as did Dan Cross)
that would work just fine, for one user.

> That's very similar to what I referred to as a "synthetic filesystem
> doing the right stuff". But as I pointed out in my original email
> this approach has a downside of never exporting these mounts
> into the namespace of the process that caused them.

You'd have the program export its own name space,
a delicate but not impossible dance.  Then its mounts
would be exported too.

> I guess I'm not quite following you here. What I'm talking about is
> a per-process modifications of namespace by some external agent
> (be it kernel driver or userspace application). As such it is not
> at all different from a user issuing something like "9fs name"
> directly.

That's fine.

> Could you, please, elaborate what exact multi-user scenario do you
> have in mind?

I was talking about multiple users sharing a single automounter,
like in modern Unixes.

Russ

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

[Roman V. Shaposhnik]

Hi, Russ!

Firs of all -- thank a lot for answering all of my question
in a very detailed manner. I really do appreciate it!
Now, if you don't mind, I still have just one question left:

On Mon, 2008-12-01 at 16:55 -0800, Russ Cox wrote:
> > That's very similar to what I referred to as a "synthetic filesystem
> > doing the right stuff". But as I pointed out in my original email
> > this approach has a downside of never exporting these mounts
> > into the namespace of the process that caused them.
>
> You'd have the program export its own name space,
> a delicate but not impossible dance.  Then its mounts
> would be exported too.

That's pretty much what I'm after. Now, the question I still have
is this: was there a clear reason behind deciding not letting the
kernel help with something like that?

I would imagine that making '#p'/<proc id>/ns writable and receptive
to messages of exact same format that is being output right now
(plus an 'unmount X Y' message)  would be a very natural thought in
a Plan9 environment. Yet, it wasn't implemented that way which makes
me believe that I do (as usual) overlook something obvious here.
Please give me a hint to what it might be that renders the idea as a bad
one.

Thanks,
Roman.

P.S. Thinking for a couple more minutes makes me believe that a
writable '#p'/<proc id>/ns might even be used to implement
mount/bind syscall. Which, on the surface, would make it even
more appealing.

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

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

On Tue, Dec 02, 2008 at 10:04:57AM -0800, Roman V. Shaposhnik wrote:
> I would imagine that making '#p'/<proc id>/ns writable and receptive
> to messages of exact same format that is being output right now
> (plus an 'unmount X Y' message)  would be a very natural thought in
> a Plan9 environment. Yet, it wasn't implemented that way which makes 
> me believe that I do (as usual) overlook something obvious here. 
> Please give me a hint to what it might be that renders the idea as a bad
> one.

Namespaces form a large part of the security component of the Plan 9 model,
and (AFAICT) cross-namespace work is underinvestigated since it starts to
look a lot like something that could compromise the system's security.  At
the moment, we can make claims like "once fork(NEWNS) succeeds, I and the
kernel are the only agents that are able to manipulate my namespace."  This
is a nice statement to be able to make.

Since /proc/$PID/ns is "mostly" an rc script, it's possible (sometimes) to
"see into" another proc's namespace by following along... given that, what
would be wrong with your /set server exporting a ns-like file that simply
detailed its own manipulations to its namespace?  You'd have to assume that
/net (or /srv, if you prefer) was shared between /set and you, I suppose...
which is probably OK.

> Thanks,
> Roman.
> 
> P.S. Thinking for a couple more minutes makes me believe that a 
> writable '#p'/<proc id>/ns might even be used to implement 
> mount/bind syscall. Which, on the surface, would make it even
> more appealing.

Intriguing.  I guess it wasn't done this way so that processes could be
constructed without /proc mounted... (though you could always manipulate
'#p/$PID/ns'... that might be considered a bug, tho')

--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 204 bytes --]

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

[Roman V. Shaposhnik]

On Tue, 2008-12-02 at 13:31 -0500, Nathaniel W Filardo wrote:
> Namespaces form a large part of the security component of the Plan 9 model,
> and (AFAICT) cross-namespace work is underinvestigated

It would be, in fact, a fair answer.

> since it starts to look a lot like something that could compromise the
> system's security.

Somehow, it doesn't strike me as any more dangerous that the rest
of files you have under #p/<id>/. But I'd love to be corrected.

> the moment, we can make claims like "once fork(NEWNS) succeeds, I and the
> kernel are the only agents that are able to manipulate my namespace."  This
> is a nice statement to be able to make.

But isn't it a tad overprotective? Although, it seems that I know of
at least one more thing that didn't make it into #p -- environment.
#e is also only accessible to the kernel and the process itself.
I have always thought that Linux got it right with /proc/self
and /proc/<id>/environ. But may be, again, I'm missing some part
of a bigger picture here.

> Since /proc/$PID/ns is "mostly" an rc script, it's possible (sometimes) to
> "see into" another proc's namespace by following along... given that, what
> would be wrong with your /set server exporting a ns-like file that simply
> detailed its own manipulations to its namespace?  You'd have to assume that
> /net (or /srv, if you prefer) was shared between /set and you, I suppose...
> which is probably OK.

I *suspect* that this is, indeed, the dance Russ was referring to.
Nothing wrong with dancing it. But it still leaves me curious
as to why it was decided to *not* implement the support in the
kernel.

Thanks,
Roman.

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

[hiro]

> I *suspect* that this is, indeed, the dance Russ was referring to.
> Nothing wrong with dancing it. But it still leaves me curious
> as to why it was decided to *not* implement the support in the
> kernel.
>
> Thanks,
> Roman.
>
>
>

I still don't understand what kind of feature you are missing. Could
it be that you just want a naming convention for your mount places?

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

[Roman V. Shaposhnik]

On Tue, 2008-12-02 at 21:05 +0100, hiro wrote:
> I still don't understand what kind of feature you are missing. Could
> it be that you just want a naming convention for your mount places?

Writable '#p/<id>/ns'

Thanks,
Roman.

P.S. Unless somebody tells me that it is a bad idea with the explanation
to back that claim up.

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

[erik quanstrom]

> On Tue, 2008-12-02 at 21:05 +0100, hiro wrote:
> > I still don't understand what kind of feature you are missing. Could
> > it be that you just want a naming convention for your mount places?
>
> Writable '#p/<id>/ns'
>
> Thanks,
> Roman.
>
> P.S. Unless somebody tells me that it is a bad idea with the explanation
> to back that claim up.

a couple of questions come to mind.  how does writing
to a ns interact with shared namespaces?  does it automaticly
fork the namespace?  seems iffy.  which leads to the next
obvious question

how do you prevent a race between changing the namespace and
opening fds?

and, what about open file descriptors?

seems like a big can of worms.

- erik

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

[Russ Cox]

> a couple of questions come to mind.  how does writing
> to a ns interact with shared namespaces?  does it automaticly
> fork the namespace?  seems iffy.  which leads to the next
> obvious question
>
> how do you prevent a race between changing the namespace and
> opening fds?
>
> and, what about open file descriptors?
>
> seems like a big can of worms.

None of these questions are any different in this
context than if there was simply some other process
sharing the name space and doing the same manipulations.

A writable #p/pid/ns seems strange to me
(not nearly as natural as Roman suggested),
but maybe it would be fine.  No one has cared
enough to explore it.

I don't think a writable #p/pid/ns would really
help you write an automounter.  You don't know
the pid you are getting the 9P request from
(maybe it is on another machine!).

If I had to write an automounter like you describe
and I was going to tweak the kernel to make it
easier, I would change name spaces to be hierarchical,
so that rfork(RFNAMEG) (or perhaps some new bit)
insulates the parent from the child's modifications
but not vice versa.  Then the automounter can sit
in some early name space and mount things, and all
the name spaces that were forked off would see them.
That is easier to reason about than writing #p/pid/ns.

Russ

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

[erik quanstrom]

> None of these questions are any different in this
> context than if there was simply some other process
> sharing the name space and doing the same manipulations.
>

currently one can prevent external changes to a
namespace by creating a unique ns with rfork.
if /proc/$pid/ns were writable, one would not not
be possible without yet another mechanism.

- erik

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

[Roman V. Shaposhnik]

On Tue, 2008-12-02 at 19:07 -0500, erik quanstrom wrote:
> > None of these questions are any different in this
> > context than if there was simply some other process
> > sharing the name space and doing the same manipulations.
> >
>
> currently one can prevent external changes to a
> namespace by creating a unique ns with rfork.
> if /proc/$pid/ns were writable, one would not not
> be possible without yet another mechanism.

>From where I sit, the file permissions seem to be quite an
adequate a measure to be used for restricting access to any
of the files under #p/<id>.

I don't see how ns is different from, lets say, mem.

Thanks,
Roman.

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

[Dan Cross]

On Tue, Dec 2, 2008 at 7:07 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> currently one can prevent external changes to a
> namespace by creating a unique ns with rfork.
> if /proc/$pid/ns were writable, one would not not
> be possible without yet another mechanism.

chmod?  I guess it comes back to, "How do you define external."  If
you mean another process owned by the same user, then it breaks down
(hello trojan horse).

There are many things that would be *possible* with /proc, some of
them ill advised.  For instance, why can't I 'mkdir /proc/n/' and have
it create a new process?  I can think of a number of potential
reasons, one of the most obvious ones is 'how do I choose n';
something more reasonable would probable be a /proc/ctl or /proc/fork
or /proc/new or something that, when read, gives me a file directory
name corresponding to a new process in some 'new' state.  Maybe
copying a binary onto /proc/n/text would and writing 'go' would be the
moral equivalent of a 'spawn'-like call.  Who knows.  I guess the
point is, "what does that *mean*?"  Ie, it would fundamentally change
the process model from something fork-based to something radically
different.  Is that good?  Is that bad?  Beats me.  I'm not sure it's
worth exploring.  I suspect opening up /proc/n/ns for tinkering would
be similar.  As Russ says, no one's felt motivated to do it.  There's
no good reason you can't explore it, but you may find it isn't as cool
as you'd originally hoped.

An aside: One of the nice things about Plan 9 is that a lot of the
things you sort of have to work around in Unix just work in Plan 9.
They applied a few fundamental principles aggressively and in so fixed
a lot of warts that had begun to glare on Unix as it aged.  I can see
the utility of an autofs-like thing, but I wouldn't get too wrapped up
in the semantics of making it look like Unix; that's not a profitable
thing in this environment, since this environment *is* different.
It's funny, the feeling you described when talking about the Sun
intranet is exactly how I felt when first working with plan 9.

That being said, one of the biggest challenges the Linux/Unix
community faces these days is a mental entrenchment and clinging to
bad technology because "that's the way it's always been."  The Plan 9
community should work hard to make sure that doesn't happen to it.

        - Dan C.

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

[Roman Shaposhnik]

On Dec 2, 2008, at 5:36 PM, Dan Cross wrote:
> On Tue, Dec 2, 2008 at 7:07 PM, erik quanstrom
> <quanstro@quanstro.net> wrote:
>> currently one can prevent external changes to a
>> namespace by creating a unique ns with rfork.
>> if /proc/$pid/ns were writable, one would not not
>> be possible without yet another mechanism.
>
> chmod?  I guess it comes back to, "How do you define external."  If
> you mean another process owned by the same user, then it breaks down
> (hello trojan horse).
>
> There are many things that would be *possible* with /proc, some of
> them ill advised.  For instance, why can't I 'mkdir /proc/n/' and have
> it create a new process?

There's an aswer to that given by Ken in the Plan 9 paper:
       http://www.cs.bell-labs.com/sys/doc/9.html:
-----------------------------------------------------------------------------------------------------
Nonetheless, it is possible to push the idea of file-based computing
too far.
Converting every resource in the system into a file system is a kind
of metaphor,
and metaphors can be abused. A good example of restraint is/proc,
which is
only a view of a process, not a representation. To run processes, the
usual
fork and exec calls are still necessary, rather than doing something
like
      cp /bin/date /proc/clone/mem
------------------------------------------------------------------------------------------------------

Thanks,
Roman.

P.S. I suppose one might argue that it is also an answer to *my*
original
question -- /proc/<id>/ns is just a representation.

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

[Dan Cross]

On Sat, Dec 6, 2008 at 12:24 AM, Roman Shaposhnik <rvs@sun.com> wrote:
>> There are many things that would be *possible* with /proc, some of
>> them ill advised.  For instance, why can't I 'mkdir /proc/n/' and have
>> it create a new process?
>
> There's an aswer to that given by Ken in the Plan 9 paper:
>      http://www.cs.bell-labs.com/sys/doc/9.html:
> -----------------------------------------------------------------------------------------------------
> Nonetheless, it is possible to push the idea of file-based computing too
> far.
> Converting every resource in the system into a file system is a kind of
> metaphor,
> and metaphors can be abused. A good example of restraint is/proc, which is
> only a view of a process, not a representation. To run processes, the usual
> fork and exec calls are still necessary, rather than doing something like
>     cp /bin/date /proc/clone/mem
> ------------------------------------------------------------------------------------------------------

My mention of that was a contrived example.  But anyway....

This explains an artifact of the implementation, not the rationale
behind it, other than that it was considered to be metaphor abuse,
which everyone kind of "knows" but no one's really said *why* it's a
bad thing.  My argument, if you chose to pick through my convoluted
wording, was that it drastically changed the process model, but it's
unknown whether that's truly a bad thing (though most reasonable
people would agree that it is).

> P.S. I suppose one might argue that it is also an answer to *my* original
> question -- /proc/<id>/ns is just a representation.

Well, that's one answer but not a very satisfying one.  I think my
point was somewhat along Russ's lines; that no one's felt the need to
explore it.

        - Dan C.

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

[Rob Pike]

On Tue, Dec 2, 2008 at 3:55 PM, Russ Cox <rsc@swtch.com> wrote:
>> a couple of questions come to mind.  how does writing
>> to a ns interact with shared namespaces?  does it automaticly
>> fork the namespace?  seems iffy.  which leads to the next
>> obvious question
>>
>> how do you prevent a race between changing the namespace and
>> opening fds?
>>
>> and, what about open file descriptors?
>>
>> seems like a big can of worms.
>
> None of these questions are any different in this
> context than if there was simply some other process
> sharing the name space and doing the same manipulations.
>
> A writable #p/pid/ns seems strange to me
> (not nearly as natural as Roman suggested),
> but maybe it would be fine.  No one has cared
> enough to explore it.
>
> I don't think a writable #p/pid/ns would really
> help you write an automounter.  You don't know
> the pid you are getting the 9P request from
> (maybe it is on another machine!).
>
> If I had to write an automounter like you describe
> and I was going to tweak the kernel to make it
> easier, I would change name spaces to be hierarchical,
> so that rfork(RFNAMEG) (or perhaps some new bit)
> insulates the parent from the child's modifications
> but not vice versa.  Then the automounter can sit
> in some early name space and mount things, and all
> the name spaces that were forked off would see them.
> That is easier to reason about than writing #p/pid/ns.
>
> Russ

Long ago I considered making the namespace not hierarchical but a set
of spaces. The first level of complexity upwards would be to have two
spaces: one that is per-process and one that is global or per-machine.
 It could of course be extended to more generality, hierarchy, etc.
The reason I didn't was that the existing one-space system was almost
good enough and any generalization seemed either too complex or too
specific.  There seemed no guiding principle to organize the design.

So I left it alone even though in so doing I was leaving a problem on the table.

-rob