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
> 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 tha
>> 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
On Sat, Dec 6, 2008 at 12:24 AM, Roman Shaposhnik <[EMAIL PROTECTED]> 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 P
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
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 bi
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 (
> 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 f
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 anywhe
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 prett
> 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 us
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 whil
> 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
> 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
On Tue, Dec 2, 2008 at 3:55 PM, Russ Cox <[EMAIL PROTECTED]> 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 r
> > 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 ge
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 ta
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
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.
> >
>
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 b
> 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
> 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
> > 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 ful
> 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//ns'
>
> Thanks,
> Roman.
>
> P.S. Unless somebody tells me that it is a bad idea wit
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//ns'
Thanks,
Roman.
P.S. Unless somebody tells me that it is a bad idea with the explanation
to
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
> > explanat
> (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.
> 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.
>> 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" se
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 compr
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
> dire
> 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//stuff... will be
> completely hi
On Tue, Dec 02, 2008 at 10:04:57AM -0800, Roman V. Shaposhnik wrote:
> I would imagine that making '#p'//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 w
On Mon, 2008-12-01 at 18:11 -0500, [EMAIL PROTECTED] 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
On Mon, 2008-12-01 at 16:18 -0500, Dan Cross wrote:
> 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/ is not there.
> > At least not by default.
>
> I see what you're after. If
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
> 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
Won't srvfs (see exportfs(4)) do what you want (packaging up a
namespace)?
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 t
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/ 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
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
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 t
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 automount
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, script
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, De
> 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
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?
>
> - erik
>
>
> 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
ans.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
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
pl
50 matches
Mail list logo
