Re: [9fans] How to implement a moral equivalent of automounter
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
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
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
On Dec 4, 2008, at 8:43 PM, erik quanstrom wrote: On Thu Dec 4 23:37:02 EST 2008, [EMAIL PROTECTED] 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 in Plan9?
On Dec 2, 2008, at 5:36 PM, Dan Cross wrote: On Tue, Dec 2, 2008 at 7:07 PM, erik quanstrom [EMAIL PROTECTED] 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
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
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
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
On Thu Dec 4 23:37:02 EST 2008, [EMAIL PROTECTED] 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
On Thu, Dec 04, 2008 at 02:58:15PM +, 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; pgpA01LMOoIjM.pgp Description: PGP signature
Re: [9fans] How to implement a moral equivalent of automounter
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 in Plan9?
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?
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; pgpMmbsCYB9pQ.pgp Description: PGP signature
Re: [9fans] How to implement a moral equivalent of automounter in Plan9?
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
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
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 in Plan9?
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?
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
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 in Plan9?
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?
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?
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
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 in Plan9?
On Tue, Dec 2, 2008 at 7:07 PM, erik quanstrom [EMAIL PROTECTED] 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
On Tue, Dec 2, 2008 at 8:26 PM, Roman V. Shaposhnik [EMAIL PROTECTED] 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 in Plan9?
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?
bns != aan On Mon, Dec 1, 2008 at 3:34 PM, erik quanstrom [EMAIL PROTECTED] 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?
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 [EMAIL PROTECTED] wrote: bns != aan On Mon, Dec 1, 2008 at 3:34 PM, erik quanstrom [EMAIL PROTECTED] 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?
On Mon, Dec 1, 2008 at 9:48 AM, Russ Cox [EMAIL PROTECTED] 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?
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 20 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?
On Mon, Dec 1, 2008 at 1:31 PM, Roman V. Shaposhnik [EMAIL PROTECTED] 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?
On Mon, 01 Dec 2008 10:25:09 PST Roman V. Shaposhnik [EMAIL PROTECTED] 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
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 Plan9?
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
