Re: [9fans] Interested in improving networking in Plan 9
Oh I don't know Shoehorning a DB interface into a FS interface doesn't feel right but stranger things have happened. I've done it a few ways. echo commit /n/db/0/ctl is kind of where one ends up for my limbo postgres module I never got round to the fs part. i just wrap the sql bits in their own adt
Re: [9fans] Interested in improving networking in Plan 9
I've done it a few ways. echo commit /n/db/0/ctl is kind of where one ends up for my limbo postgres module I never got round to the fs part. i just wrap the sql bits in their own adt i would think that rather than use an adt, one would want to make the language the communication's protocol. it seems so straightforward to just send formatted sql or pl/sql to the engine and get normally formatted output. one could just con to the engine and type away for testing. even if you've degenerated the fs to a pipe like /net/tcp/nn, it's still quite useful to see who is connected and you can import the connection easily. this isn't too far from what sql*net does, except they need to deal with sockets. they may also do wierd formatting of the data stream. - erik
Re: [9fans] Interested in improving networking in Plan 9
[...] but... SQL is really ugly. it's not hard to construct something that provides the same functionality in a much more palatable form. aesthetics aside, if you're dealing with a database-heavy app, it can make the code much easier to read. could you explain what in particular is objectionable about sql? i wrote about 100k lines of sql and pl/sql for a 1tb database in the late ninties. (doesn't sound very big anymore.) i found it easy to develop, read and maintain. it almost felt like cheating. there was about 100k lines of application / web stuff that went along with it. not any harder but a lot less general is the option of wrapping the database around a higher-level abstraction. you can do things like data constraints and validations in the application code, rather than in the sql database itself, which always feels like this random bolt-on to the application logic. of course this is a difficult roe to hoe. the database can change table.name from varchar(10) to varchar(32) without consulting the application code, or vice versa. seperating the constraining fact from the constraint seems like a fundamental error to me. alternatively, one can just as easily use stored procedures to validate input. then the validation can work against the live constraints. checks like the document.id must be a valid document.id can be done race-free in a stored procedure without doing a dance between the application and db while holding a transaction lock. - erik
Re: [9fans] Interested in improving networking in Plan 9
On Thu, Sep 3, 2009 at 5:13 PM, Anthony Sorace ano...@gmail.com wrote: i've not used matt's sql module itself (i should check it out) so i can't comment on his implementation, but... SQL is really ugly. it's not hard to construct something that provides the same functionality in a much more palatable form. aesthetics aside, if you're dealing with a database-heavy app, it can make the code much easier to read. SQL in itself is actually pretty elegant for what it is intended, querying relational tables. The problem with databases is more one of really bad design. A badly designed database makes SQL use awkward. Using a more general programming language allows you to create abstractions that hide the hideous database. It ends up as a veneer that usually grows and grows and grows trying to fix problems that actually exist at the database level itself. The fact that using SQL against your database is a pain, should really signal alarm bells and make you investigate what may be wrong with its design. Robby
Re: [9fans] Interested in improving networking in Plan 9
it seems so straightforward to just send formatted sql or pl/sql to the engine and get normally formatted output. I did somthing like this for mysql to access our corperate telephone database. I took the inferno odbcfs as an example: http://www.vitanuova.com/inferno/man/10/odbc.html if interested see the steve/mysqlfs contrib package -Steve
Re: [9fans] Interested in improving networking in Plan 9
On Sep 3, 2009, at 10:13 AM, Anthony Sorace wrote: you can do things like data constraints and validations in the application code, rather than in the sql database itself, which always feels like this random bolt-on to the application logic. I think it's useful to think of relational databases as integration technology rather than merely storage technology. Having everything important in the application layer means you have to go through the application layer to do anything. Part of the point of SQL and RDBMSes being so complex is that it liberates the data from any one particular application that wants to access the data. This fact is often forgotten these days because most databases are only accessed through the web via one app. But I usually find that eventually one needs to get at the data directly, for reporting, maintenance or some other task that isn't intrinsically part of the website. Then the database can take on the data management role and make sure you don't make your data incomprehensible, as well as provide you with a little security. Of course, it's best of all if you have a database that supports things like views; otherwise you will need application code to have any abstractions at all. — Daniel Lyons
Re: [9fans] Interested in improving networking in Plan 9
On Mon, 31 Aug 2009 11:33:13 CDT Eric Van Hensbergen eri...@gmail.com wrote: On Mon, Aug 31, 2009 at 11:16 AM, Bakul Shahbakul+pl...@bitblocks.com wrote: An intriguing idea that can point toward a synth fs interface to a dbms or search results But I don't think this would be a lightweight interface. The fact that its not immediately clear is what makes it a good research topic. It will likely take several iterations to identify a best fit interface with the likely result that multiple interfaces/views are required. I think there are precious little information on synthetic file system design, given its continuing popularity in the non-Plan-9 world, we could use more published wisdom/experiences from the evolution of various file-system based interfaces. Oh I don't know Shoehorning a DB interface into a FS interface doesn't feel right but stranger things have happened.
Re: [9fans] Interested in improving networking in Plan 9
On Wed, Sep 2, 2009 at 5:50 PM, Bakul Shah bakul+pl...@bitblocks.combakul%2bpl...@bitblocks.com wrote: On Mon, 31 Aug 2009 11:33:13 CDT Eric Van Hensbergen eri...@gmail.com wrote: On Mon, Aug 31, 2009 at 11:16 AM, Bakul Shahbakul+pl...@bitblocks.combakul%2bpl...@bitblocks.com wrote: An intriguing idea that can point toward a synth fs interface to a dbms or search results But I don't think this would be a lightweight interface. The fact that its not immediately clear is what makes it a good research topic. It will likely take several iterations to identify a best fit interface with the likely result that multiple interfaces/views are required. I think there are precious little information on synthetic file system design, given its continuing popularity in the non-Plan-9 world, we could use more published wisdom/experiences from the evolution of various file-system based interfaces. Oh I don't know Shoehorning a DB interface into a FS interface doesn't feel right but stranger things have happened. There are some folk about who are working on a distributed spreadsheet ( hypernumbers.com, there used to be a trial system up and lots of documents, but I'm not sure where that all went, and I can't be bothereed signing up just now, they're presenting at ICFP CUFP on Friday, so the company/project should still be properly alive). Anyway, the idea they've got is that every cell in a spreadsheet has a URL and you can reference and use cells across a distributed space. Interesting idea, but I'm not entirely sure what to do with it, being spreadsheet-challenged myself. Robby
Re: [9fans] Interested in improving networking in Plan 9
On Aug 30, 2009, at 10:34 PM, erik quanstrom quans...@quanstro.net wrote: On Sun Aug 30 14:37:29 EDT 2009, rminn...@gmail.com wrote: One way to make this kind of interesting is to address how you'd do a reasonable zeroconf effort given that you need to boot 1m+ machines. We've booted 4400*250 VMs on a machine at sandia, and, let me tell you, it was a pain. It is amusing to watch the programs traverse million line /etc/hosts file -- for a while. how does this apply to plan 9? ndb already provides for indexed databases. but i have not tried this with millions of entries. I think there are a few issues beyond will it scale - of course with 128k nodes scaling is a baseline prereq for us. On BG we have a segmented network to deal with -- but it's likely you'll want some form of hierarchy regardless. I have done much with dynamic service registry using DNS in plan 9 - maybe it's easy and just not well documented. Then there's issue of locality - finding the registered service that is closest to you. Then there is load balancing - finding the closest service whch isn't heavily loaded. Then there is dealing with reliability, security, and so forth and so on.
Re: [9fans] Interested in improving networking in Plan 9
I think there are a few issues beyond will it scale - of course with 128k nodes scaling is a baseline prereq for us. On BG we have a segmented network to deal with -- but it's likely you'll want some form of hierarchy regardless. I have done much with dynamic service registry using DNS in plan 9 - maybe it's easy and just not well documented. i'm sure there are. could you explan why you're focused on dns? a more natural way to use plan 9 would be to use ndb and cs directly. wouldn't it? by the way, ndb/cs is already a program that replaces a static file. why couldn't you use it to do these interesting lookups? it already has some specialized knowledge of protocols. it seems like the place for these things. i've probablly just given away my vast ignorance. please set me straight. :-) - erik
Re: [9fans] Interested in improving networking in Plan 9
You can implement a NAT by mounting a /net from a perimeter machine with a public IP, while connecting to it from an internal network of private IP addresses, using the Plan 9 protocol 9P in the internal network. This is from the wikipedia page on Plan 9 OS. Is something like iptables like in linux needed to be implemented for Plan 9 ? Again forgive me if I came out looking like an idiot ! On Mon, Aug 31, 2009 at 6:21 PM, erik quanstromquans...@quanstro.net wrote: I think there are a few issues beyond will it scale - of course with 128k nodes scaling is a baseline prereq for us. On BG we have a segmented network to deal with -- but it's likely you'll want some form of hierarchy regardless. I have done much with dynamic service registry using DNS in plan 9 - maybe it's easy and just not well documented. i'm sure there are. could you explan why you're focused on dns? a more natural way to use plan 9 would be to use ndb and cs directly. wouldn't it? by the way, ndb/cs is already a program that replaces a static file. why couldn't you use it to do these interesting lookups? it already has some specialized knowledge of protocols. it seems like the place for these things. i've probablly just given away my vast ignorance. please set me straight. :-) - erik -- Vinu Rajashekhar, 5th Year Dual Degree Student, Deptt of Computer Science Engg, IIT Kharagpur, India.
Re: [9fans] Interested in improving networking in Plan 9
You can implement a NAT by mounting a /net from a perimeter machine with a public IP, while connecting to it from an internal network of private IP addresses, using the Plan 9 protocol 9P in the internal network. This is from the wikipedia page on Plan 9 OS. Is something like iptables like in linux needed to be implemented for Plan 9 ? Again forgive me if I came out looking like an idiot ! not at all. of course this only works for computers that can import /net. just theoretically suppose that your gateway is a plan 9 machine and someone in the house has a windows box. nat would be useful for supporting the windows box that can't import /net. some people would argue that a lot of modems can do the nat so why bother. the reason to bother is to (a) avoid buggy modem firmware and (b) to integrate nat into the rest of one's network services so things like logging, etc. are uniform. and you don't have to deal with the modems dumb http interface. :-) - erik
Re: [9fans] Interested in improving networking in Plan 9
On Mon, Aug 31, 2009 at 7:51 AM, erik quanstromquans...@quanstro.net wrote: could you explan why you're focused on dns? a more natural way to use plan 9 would be to use ndb and cs directly. wouldn't it? Of course. My use of DNS was really just in abstract to refer to the suite of existing services for name and service resolution under Plan 9. However, I think the current interfaces for ndb and cs are very limiting and the single file based query mechanisms don't really match the hierarchical style of the rest of the system. If there is a masters project in here, its to look at a revision of the whole suite and extension of the relevant file system based interfaces. The other side of this is then to integrate this new service registration/discovery mechanism to existing applications. When I export, a flag should make that export visible to zeroconf resolution, etc. -eric
Re: [9fans] Interested in improving networking in Plan 9
that wiki writeup isn't really right. importing /net isn't NAT in any sort of technical sense; rather, it's what plan 9 does instead. there's no translation of ports or addresses, it's more (conceptually) like a straight multiplexing.
Re: [9fans] Interested in improving networking in Plan 9
Of course. My use of DNS was really just in abstract to refer to the suite of existing services for name and service resolution under Plan 9. However, I think the current interfaces for ndb and cs are very limiting and the single file based query mechanisms don't really match the hierarchical style of the rest of the system. If there is a masters project in here, its to look at a revision of the whole suite and extension of the relevant file system based interfaces. The other side of this is then to integrate this new service i definately think there's room for improvement, but i would hate for ndb to morph into the windows registry. the main situation where ndb is weak is when there are rapid changes. otherwise ndb/cs and ndb/mkhash should make it unnecessary to scan whole files. given the database= option, if one could confine rapid changes to smaller files, one could teach ndb to only reread changed files. registration/discovery mechanism to existing applications. When I export, a flag should make that export visible to zeroconf resolution, etc. what do you mean by export? - erik
Re: [9fans] Interested in improving networking in Plan 9
On Mon, Aug 31, 2009 at 9:04 AM, erik quanstromquans...@quanstro.net wrote: given the database= option, if one could confine rapid changes to smaller files, one could teach ndb to only reread changed files. Why not have a synthetic file system interface to ndb that allows it to update its own files? I think this is my primary problem. Granular modification to static files is a PITA to manage -- we should be using synthetic file system interfaces to to help manage and gate modifications. Most of the services I have in mind may be transient and task specific, so there are elements of scope to consider and you may not want to write anything out to static storage. registration/discovery mechanism to existing applications. When I export, a flag should make that export visible to zeroconf resolution, etc. what do you mean by export? When I publish a service, in the Plan 9 case primarily by exporting a synthetic file system. I shouldn't have to have static configuration for file servers, it should be much more fluid. I'm not arguing for a microsoft style registry -- but the network discovery environment on MacOSX is much nicer than what we have today within Plan 9. An even better example is the environment on the OLPC, where many of the applications are implicitly networked and share resources based on Zeroconf pub/sub interfaces. -eric
Re: [9fans] Interested in improving networking in Plan 9
given the database= option, if one could confine rapid changes to smaller files, one could teach ndb to only reread changed files. Why not have a synthetic file system interface to ndb that allows it to update its own files? I think this is my primary problem. Granular modification to static files is a PITA to manage -- we should be using synthetic file system interfaces to to help manage and gate modifications. Most of the services I have in mind may be transient and task specific, so there are elements of scope to consider and you may not want to write anything out to static storage. i can see in principle how this could be a good idea (no more comments, though). could you elaborate, though. i have found editing /lib/ndb/local works well at the scales i see. i also don't know what you mean by transient, task specific services. i can only think of things like ramfs or cdfs. but they live in my namespace so ndb doesn't enter into the picture. could you give an example? When I publish a service, in the Plan 9 case primarily by exporting a synthetic file system. I shouldn't have to have static configuration for file servers, it should be much more fluid. I'm not arguing for a microsoft style registry -- but the network discovery environment on MacOSX is much nicer than what we have today within Plan 9. An even better example is the environment on the OLPC, where many of the applications are implicitly networked and share resources based on Zeroconf pub/sub interfaces. sounds interesting. but i don't understand what you're talking about exactly. maybe you're thinking that cpu could be rigged so that cpu with no host specifier would be equivalent to cpu -h '$boredcpu' where '$boredcpu' would be determined by cs via dynamic mapping? or am i just confused? - erik
Re: [9fans] Interested in improving networking in Plan 9
2009/8/31 Vinu Rajashekhar vinuthe...@gmail.com: You can implement a NAT by mounting a /net from a perimeter machine with a public IP, while connecting to it from an internal network of private IP addresses, using the Plan 9 protocol 9P in the internal network. This is from the wikipedia page on Plan 9 OS. Is something like iptables like in linux needed to be implemented for Plan 9 ? My student's summer of code project, which was quite unfortunately not completed, was to implement support for NAT in Plan 9, and to implement a firewalling infrastructure. I think it would be good to implement something like this, and several people thought that implementing NAT, if done correctly, would be quite useful for people running Plan 9. I'm still interested in providing guidance and info about this if it's something you're interested in pursuing -- I have quite a few ideas on how it should work. Kind regards, Devon H. O'Dell
Re: [9fans] Interested in improving networking in Plan 9
Hmmm. we did that for FS processes on Plan B. I mean, keep a dynamic version of a registry. It kept the list of volumes available at a central place. I think it can be used as is on Plan 9, without changes. There was a program (I think it was called adsrv; not sure, it´s on the Plan B man pages) were file servers could keep an open file as long as they were alive. We didn´t do load balancing but it shouldn´t be hard to add that to this program. If there´s interest I can dig in our worm (although it should be also on sources). On Mon, Aug 31, 2009 at 4:25 PM, Eric Van Hensbergeneri...@gmail.com wrote: On Mon, Aug 31, 2009 at 9:04 AM, erik quanstromquans...@quanstro.net wrote: given the database= option, if one could confine rapid changes to smaller files, one could teach ndb to only reread changed files. Why not have a synthetic file system interface to ndb that allows it to update its own files? I think this is my primary problem. Granular modification to static files is a PITA to manage -- we should be using synthetic file system interfaces to to help manage and gate modifications. Most of the services I have in mind may be transient and task specific, so there are elements of scope to consider and you may not want to write anything out to static storage. registration/discovery mechanism to existing applications. When I export, a flag should make that export visible to zeroconf resolution, etc. what do you mean by export? When I publish a service, in the Plan 9 case primarily by exporting a synthetic file system. I shouldn't have to have static configuration for file servers, it should be much more fluid. I'm not arguing for a microsoft style registry -- but the network discovery environment on MacOSX is much nicer than what we have today within Plan 9. An even better example is the environment on the OLPC, where many of the applications are implicitly networked and share resources based on Zeroconf pub/sub interfaces. -eric
Re: [9fans] Interested in improving networking in Plan 9
On Mon, Aug 31, 2009 at 9:36 AM, erik quanstromquans...@quanstro.net wrote: i can see in principle how this could be a good idea (no more comments, though). could you elaborate, though. i have found editing /lib/ndb/local works well at the scales i see. I think the main issue with just editing /lib/ndb/local is a combination of scale and number of writers. Writing static config files could work fine in a typical plan 9 network of hundreds of machines, even with multiple admins. I have a feeling it starts to break down with thousands of machines, particularly in an environment where machines are appearing and disappearing at regular intervals (clouds, HPC partitioning, or Blue Gene). Hundreds of thousands of nodes with this sort of behavior probably makes it impractical. Of course -- this won't effect the casual user, but its something that effects us. Its also possible that such a dynamic environment would better support a 9grid style environment. i also don't know what you mean by transient, task specific services. i can only think of things like ramfs or cdfs. but they live in my namespace so ndb doesn't enter into the picture. There is the relatively mundane configuration examples of publishing multiple file servers, authentication servers, and cpu servers. There's a slightly more interesting example of more pervasive sharing (imagine sharing portions of your ACME file system to collaborate with several co-authors, or for code review). The more applications which export synthetic file systems, the more opportunity there is for sharing and requiring a broader pub/sub interface. There is another option here which I'm side-stepping because its something I'm actively working on -- which is instead of doing such a pub/sub interface within ndb and CS, extending srv to provide a registry for cluster/grid/cloud. However, underneath it may still be nice to have zeroconf as a pub/sub for interoperation with non-Plan 9 systems. When I publish a service, in the Plan 9 case primarily by exporting a synthetic file system. I shouldn't have to have static configuration for file servers, it should be much more fluid. I'm not arguing for a microsoft style registry -- but the network discovery environment on MacOSX is much nicer than what we have today within Plan 9. An even better example is the environment on the OLPC, where many of the applications are implicitly networked and share resources based on Zeroconf pub/sub interfaces. sounds interesting. but i don't understand what you're talking about exactly. maybe you're thinking that cpu could be rigged so that cpu with no host specifier would be equivalent to cpu -h '$boredcpu' where '$boredcpu' would be determined by cs via dynamic mapping? or am i just confused? Actually, the idea would be that cpu's default behavior would be to go grab $boredcpu -- but that's part of the idea. That would make adding cpu servers as easy as booting them -- they'd publish their service with zeroconf and everyone would automatically pick it up and be able to query them for additional attributes related to utilization, authentication, or even fee-structures. Of course, as a I alluded to earlier, I think its much more interesting in the presence of pervasive network services exported through file systems. I'd suggest those who haven't to go grab sugar on a stick from the OLPC folks and run it under vmware or whatever. I'm not broadly endorsing every aspect of their environment, but I really liked their loosely coupled sharing/collaboration framework built upon zeroconf and their mesh networks (it may be a bit hard to see this on sugar on a stick, but there were in the past several public OLPC zeroconf servers you could attach to and play around. -eric
Re: [9fans] Interested in improving networking in Plan 9
On Mon, Aug 31, 2009 at 8:21 PM, Devon H. O'Delldevon.od...@gmail.com wrote: 2009/8/31 Vinu Rajashekhar vinuthe...@gmail.com: You can implement a NAT by mounting a /net from a perimeter machine with a public IP, while connecting to it from an internal network of private IP addresses, using the Plan 9 protocol 9P in the internal network. This is from the wikipedia page on Plan 9 OS. Is something like iptables like in linux needed to be implemented for Plan 9 ? My student's summer of code project, which was quite unfortunately not completed, was to implement support for NAT in Plan 9, and to implement a firewalling infrastructure. I think it would be good to implement something like this, and several people thought that implementing NAT, if done correctly, would be quite useful for people running Plan 9. I'm still interested in providing guidance and info about this if it's something you're interested in pursuing -- I have quite a few ideas on how it should work. Yea I did see that it was accepted as a project, but I couldn't see the actual sources or anything, so I assumed it may have got stalled. I am interested in it, from an overall point of view, but right now I am don't know enough about Plan 9 to give any constructive ideas. Still climbing the learning curve ! Thanks for responding though. Kind regards, Devon H. O'Dell -- Vinu Rajashekhar, 5th Year Dual Degree Student, Deptt of Computer Science Engg, IIT Kharagpur, India.
Re: [9fans] Interested in improving networking in Plan 9
i can see in principle how this could be a good idea (no more comments, though). could you elaborate, though. i have found editing /lib/ndb/local works well at the scales i see. [...] machines, even with multiple admins. I have a feeling it starts to break down with thousands of machines, particularly in an environment where machines are appearing and disappearing at regular intervals (clouds, HPC partitioning, or Blue Gene). Hundreds of thousands of nodes with this sort of behavior probably makes it impractical. Of course -- this won't effect the casual user, but its something that effects us. so plunkers like us with a few hundred machines are just casual users? i'd hate for plan 9 to become harder to use outside a hpc environment. it would be good to be flexable enough to support fairly degnerate cases like just flat files. i also don't know what you mean by transient, task specific services. i can only think of things like ramfs or cdfs. but they live in my namespace so ndb doesn't enter into the picture. There is the relatively mundane configuration examples of publishing multiple file servers, authentication servers, and cpu servers. how many file servers and authentication servers are you running? - erik
Re: [9fans] Interested in improving networking in Plan 9
While that sounds interesting and may be useful in its own right, a centralized server isn't really desirable -- part of the nice thing of zeroconf is moving to a decentralized environment, and ideally doing it in a scalable fashion (which isn't trivial on hundreds of thousands of cores, we certainly don't want unrestricted multicast in such an environment lest we drown in our own vomit of multicast queries and responses). Inferno also has a dynamic registry service available as another example implementation. However -- I think embracing some internet standards wouldn't be a bad thing -- DNS is certainly an existing example of an external protocol we support even though we could have invented our own. Extending the DNS support to mDNS and DNS-SD shouldn't be that big of a deal -- and most of the hard work is in defining the Plan 9 interface not actually writing the protocol support. It would allow us to play nice with other systems, which may be very beneficial in xcpu environments (which also currently suffers from a static configuration), and in particular on our Blue Gene work where front-end nodes are typically Linux or MacOSX workstations. dns is a bad protocol to build on. it's not really secure and the security measures are onerous. not to be confused with a technical argument for or against building on top of dns, but it's worth noting that ndb/dns has been pushed just about as far as it can go. it tends to suffer from cache funnies and can leak memory. i'm hoping that i can get a chance to build a thread library based dns server in the near future. - erik
Re: [9fans] Interested in improving networking in Plan 9
On Mon, 31 Aug 2009 09:25:36 CDT Eric Van Hensbergen eri...@gmail.com wrote: Why not have a synthetic file system interface to ndb that allows it to update its own files? I think this is my primary problem. Granular modification to static files is a PITA to manage -- we should be using synthetic file system interfaces to to help manage and gate modifications. Most of the services I have in mind may be transient and task specific, so there are elements of scope to consider and you may not want to write anything out to static storage. ndb maps directly to a list of lisp's association lists but how would you map this to a synthetic fs? Something like attr/value to yield a tuple? For example: % cat ndb/ip/198.41.0.4 # same as ndbquery ip 198.41.0.4 dom=A.ROOT-SERVERS.NET ip=198.41.0.4 % cat ndb/dom/A.ROOT-SERVERS.NET dom=A.ROOT-SERVERS.NET ip=198.41.0.4 But this is nasty! % cat ndb/dom/'' # same as ndbquery dom '' dom= ns=A.ROOT-SERVERS.NET ns=B.ROOT-SERVERS.NET ns=C.ROOT-SERVERS.NET ns=D.ROOT-SERVERS.NET ns=E.ROOT-SERVERS.NET ns=F.ROOT-SERVERS.NET ns=G.ROOT-SERVERS.NET ns=H.ROOT-SERVERS.NET ns=I.ROOT-SERVERS.NET ns=J.ROOT-SERVERS.NET ns=K.ROOT-SERVERS.NET ns=L.ROOT-SERVERS.NET ns=M.ROOT-SERVERS.NET And it is not clear how you would map % ndbquery attr value rattr ... Another alternative is to map each tuple to a directory: % ls ndb/dom/A.ROOT-SERVERS.NET # just show the attributes! dom ip % grep '' ndb/dom/A.ROOT-SERVERS.NET/* dom:A.ROOT-SERVERS.NET ip:198.41.0.4 An intriguing idea that can point toward a synth fs interface to a dbms or search results But I don't think this would be a lightweight interface.
Re: [9fans] Interested in improving networking in Plan 9
On Mon, Aug 31, 2009 at 10:52 AM, erik quanstromquans...@coraid.com wrote: so plunkers like us with a few hundred machines are just casual users? i'd hate for plan 9 to become harder to use outside a hpc environment. it would be good to be flexable enough to support fairly degnerate cases like just flat files. I don't disagree. Worst case, this is a complementary platform for large-scale deployments, best case is that its an alternative interface that also improves the experience for the casual user -- I think the main benefit here will be in establishing better mechanisms for collaboration amongst casual users. If any aspect of this makes things more complicated, we are doing something wrong. The whole point of going zeroconf is to make configuration simple. i also don't know what you mean by transient, task specific services. i can only think of things like ramfs or cdfs. but they live in my namespace so ndb doesn't enter into the picture. There is the relatively mundane configuration examples of publishing multiple file servers, authentication servers, and cpu servers. how many file servers and authentication servers are you running? From a file server perspective on blue gene, a full scale rack will have thousands. we're currently operating without auth (in part due to configuration issues), so I don't know how well it will scale. The other aspect here is that in current configurations, every run has a different machine configuration based on what you request from the job scheduler and what you actually get. We pretty much get different IP addresses every time, with different front ends, different file servers, etc. etc. Again though - the idea is to use file systems more pervasively within the applications as well -- so there may be multiple file servers per node providing different services depending on workload needs at the particular point of computation. Read our MTAGS paper from last year's supercomputing conference to get a bigger picture view on how we view services coming, going, migrating, and adapting to changing application usage and failure. -eric
Re: [9fans] Interested in improving networking in Plan 9
On Mon, Aug 31, 2009 at 11:16 AM, Bakul Shahbakul+pl...@bitblocks.com wrote: ndb maps directly to a list of lisp's association lists but how would you map this to a synthetic fs? Something like attr/value to yield a tuple? For example: My current intuition in these situations is to allow for both interfaces -- top level aggregated queries as well as granular hierarchical queries. Both make sense for different reasons. An intriguing idea that can point toward a synth fs interface to a dbms or search results But I don't think this would be a lightweight interface. The fact that its not immediately clear is what makes it a good research topic. It will likely take several iterations to identify a best fit interface with the likely result that multiple interfaces/views are required. I think there are precious little information on synthetic file system design, given its continuing popularity in the non-Plan-9 world, we could use more published wisdom/experiences from the evolution of various file-system based interfaces. -eric
Re: [9fans] Interested in improving networking in Plan 9
2009/8/31 Bakul Shah bakul+pl...@bitblocks.com: But this is nasty! % cat ndb/dom/'' # same as ndbquery dom '' No, the nasty part is really that the file should be called `.' and the filesystem reserves dot as the reference to the current directory. You could probably call the file `dot' or `root' (cat ndb/dom/dot or cat ndb/dom/root) as something that shouldn't ever conflict with anything else -- but the root of DNS is not an empty string. aren't you being a little bit pedantic? quoting is a fact of life. we don't say that it's evil to need to quote or transform things in rc or smtp to deal with local requirements. why would it be evil to quote '.'? and why would be calling '.' 'root' or 'dot' rather than '' be any less evil? - erik
Re: [9fans] Interested in improving networking in Plan 9
2009/8/31 erik quanstrom quans...@coraid.com: 2009/8/31 Bakul Shah bakul+pl...@bitblocks.com: But this is nasty! % cat ndb/dom/'' # same as ndbquery dom '' No, the nasty part is really that the file should be called `.' and the filesystem reserves dot as the reference to the current directory. You could probably call the file `dot' or `root' (cat ndb/dom/dot or cat ndb/dom/root) as something that shouldn't ever conflict with anything else -- but the root of DNS is not an empty string. aren't you being a little bit pedantic? quoting is a fact of life. we don't say that it's evil to need to quote or transform things in rc or smtp to deal with local requirements. why would it be evil to quote '.'? and why would be calling '.' 'root' or 'dot' rather than '' be any less evil? It's (in my opinion) slightly less evil because if(!strlen(name)) seems like a pretty poor way to determine that you're looking at the root zone. It's also more intuitive and easier to document that you're looking at the root than saying `to find root, look for a file named as an empty string'. So: less evil because it makes code more intuitive and it makes documentation easier. Also, I think I should state that I really don't care about implementation as long as it's documented, and that the root is not an empty string. I don't particularly care about quoting at all, and I don't consider that any reason for one method to be more obtuse than another. --dho - erik
Re: [9fans] Interested in improving networking in Plan 9
2009/8/31 Bakul Shah bakul+pl...@bitblocks.com: But this is nasty! % cat ndb/dom/'' # same as ndbquery dom '' No, the nasty part is really that the file should be called `.' and the filesystem reserves dot as the reference to the current directory. You could probably call the file `dot' or `root' (cat ndb/dom/dot or cat ndb/dom/root) as something that shouldn't ever conflict with anything else -- but the root of DNS is not an empty string. --dho dom= ns=A.ROOT-SERVERS.NET ns=B.ROOT-SERVERS.NET ns=C.ROOT-SERVERS.NET ns=D.ROOT-SERVERS.NET ns=E.ROOT-SERVERS.NET ns=F.ROOT-SERVERS.NET ns=G.ROOT-SERVERS.NET ns=H.ROOT-SERVERS.NET ns=I.ROOT-SERVERS.NET ns=J.ROOT-SERVERS.NET ns=K.ROOT-SERVERS.NET ns=L.ROOT-SERVERS.NET ns=M.ROOT-SERVERS.NET And it is not clear how you would map % ndbquery attr value rattr ... Another alternative is to map each tuple to a directory: % ls ndb/dom/A.ROOT-SERVERS.NET # just show the attributes! dom ip % grep '' ndb/dom/A.ROOT-SERVERS.NET/* dom:A.ROOT-SERVERS.NET ip:198.41.0.4 An intriguing idea that can point toward a synth fs interface to a dbms or search results But I don't think this would be a lightweight interface.
Re: [9fans] Interested in improving networking in Plan 9
It's (in my opinion) slightly less evil because if(!strlen(name)) seems like a pretty poor way to determine that you're looking at the root zone. It's also more intuitive and easier to document that you're looking at the root than saying `to find root, look for a file named as an empty string'. So: less evil because it makes code more intuitive and it makes documentation easier. having the root be '' makes sense to me. having it be otherwise, say dot would mean that one would properly request example.net.dot not example.net and implies that there are other roots than dot. - erik
[9fans] Interested in improving networking in Plan 9
Hi, I was looking for some open-source implementation work to be done as my master's project when I chanced upon the Plan 9 GSOC projects page. My interest is in networking, so I was particularly interested in projects about adding zeroconf networking and firewall support to Plan 9. I think I have sufficient knowledge of C/C++, but I haven't ever worked or used Plan 9, but have heard of it, so I would like to take this opportunity to get to know the system better and contribute to the community. I have a year with me to do the project, though the coursework is interlaced with classes, so I won't be able to dedicate 30-40 hrs per week like the GSOC students do ! So a year is a sufficient enough time I guess. Can someone please discuss with me how to proceed, and what are the things I should learn before starting on this ? I have already started reading the papers on Plan 9 and is starting to install the plan 9 on virtual box on my machine. -- Vinu Rajashekhar, 5th Year Dual Degree Student, Deptt of Computer Science Engg, IIT Kharagpur, India.
Re: [9fans] Interested in improving networking in Plan 9
I think your first, best bet is to try to find out what the Plan 9 community needs, rather than adding on something that might not be the that important. I have not heard anyone express a need for zeroconf in Plan 9, but maybe I'm missing something. Simple example: file systems on Plan 9 are slow. Why is that? How do they work? How would you go about finding out how to make them faster? Linux has oprofile and (now) ftrace. Would either of these be helpful? Another simple example: networking on Plan 9 could be faster. What makes it less than it could be? How would you figure out how to fix it? Another example: we don't have much in the way of current graphics drivers. Why is that? How would you fix it? One mechanism we use to support graphics is VESA mode, which does not work in SMP. Why is that? Could you fix VESA code to work in SMP? This last project (VESA) is pretty self-contained and easily defined, you might want to start there. I think you need to spend some time climbing the learning curve before picking a project. ron
Re: [9fans] Interested in improving networking in Plan 9
On Sun, Aug 30, 2009 at 9:21 AM, ron minnichrminn...@gmail.com wrote: I think your first, best bet is to try to find out what the Plan 9 community needs, rather than adding on something that might not be the that important. I have not heard anyone express a need for zeroconf in Plan 9, but maybe I'm missing something. He was mining the GSoC idea archives -- and I had expressed a desire for zeroconf -- I'd really like to get rid of /lib/ndb/local as much as such a thing would be possible. We also need it for Blue Gene and Cloud environments since IP addresses are subject to change and need discovery. The zeroconf support itself is actually kind of trivial -- its coming up with a reasonable synthetic file system interface (for discovery as well as publishing) which would be the real contribution. -eric
Re: [9fans] Interested in improving networking in Plan 9
Simple example: file systems on Plan 9 are slow. Why is that? How do they work? How would you go about finding out how to make them faster? which ones? there are quite a number to choose from. i've found that ken's fs beats the pants off nfs on similar hardware with literally one cpu tied behind its back. - erik
Re: [9fans] Interested in improving networking in Plan 9
personally, i think the best contributions come from people who have a real personal need or better want to solve a problem, solve it and contribute the solution back to the community. i think that's why unix and plan 9 exist at all. so i would encourage folks who would like to contribute to find stuff they're intereted in. i also think that it may be a good idea for us to figure out how to help folks who would like to take on projects like this do so outside the framework of gsoc. i'm willing to contribute time to that end. - erik
Re: [9fans] Interested in improving networking in Plan 9
On Sun, Aug 30, 2009 at 10:52 PM, erik quanstromquans...@quanstro.net wrote: personally, i think the best contributions come from people who have a real personal need or better want to solve a problem, solve it and contribute the solution back to the community. Yes, I do agree with that. i think that's why unix and plan 9 exist at all. so i would encourage folks who would like to contribute to find stuff they're intereted in. i also think that it may be a good idea for us to figure out how to help folks who would like to take on projects like this do so outside the framework of gsoc. I wasn't thinking about doing this as a GSOC project, I wanted to do something for my master's project which was a hardcore open-source implementation, that's why I was going through the gsoc ideas page. i'm willing to contribute time to that end. - erik -- Vinu Rajashekhar, 5th Year Dual Degree Student, Deptt of Computer Science Engg, IIT Kharagpur, India.
Re: [9fans] Interested in improving networking in Plan 9
On Sun, Aug 30, 2009 at 1:07 PM, erik quanstromquans...@quanstro.net wrote: Simple example: file systems on Plan 9 are slow. Why is that? How do they work? How would you go about finding out how to make them faster? which ones? there are quite a number to choose from. i've found that ken's fs beats the pants off nfs on similar hardware with literally one cpu tied behind its back. Try this - build the source to charon over a 200ms link over 9p. Then try again over sshfs. Also, look at a single terminal with a local fossil install. Trace the path of an 'ls /'. Count the number of copies and context switches. Having the fastest file server in the world means nothing for file system performance when your path to it is a maze of twisty passages, all alike. -- vs
Re: [9fans] Interested in improving networking in Plan 9
I wasn't thinking about doing this as a GSOC project, I wanted to do something for my master's project which was a hardcore open-source implementation, that's why I was going through the gsoc ideas page. makes sense to me. i'd incourage you to work a bit with the community. part of open source is fitting in with the community. also, there are two related ip projects that might be of interest to you: nat (non existent) and ip6 (needs work). - erik
Re: [9fans] Interested in improving networking in Plan 9
Try this - build the source to charon over a 200ms link over 9p. Then try again over sshfs. why would you do this? why not run the compile closer to the source. this is the power of plan 9. Also, look at a single terminal with a local fossil install. Trace the path of an 'ls /'. Count the number of copies and context switches. Having the fastest file server in the world means nothing for file system performance when your path to it is a maze of twisty passages, all alike. again, this is not a typical install for a performance-sensitive system. and i don't know that anyone ever claimed fossil to be a high-performance file system. running a file system in user space is a matter of convienence, not performance. at coraid, we run a stand-alone ken's file server. ken's file server has no user space. so while there are context switches, those are really speedy. they take maybe a few hundred cycles. the real win is that no data is copied from/to user space and there is one global page table that is never changed. there are no tlb flushes. those can hurt. before the switch to nupas, we averaged 200MB/s of fileserver traffic during the day to 50 clients on a single, fairly pedestrian xeon 5000 machine with 3.5gb of usable memory. perhaps my standards are low and i'm out of touch, but i don't think nfs could do that well with that little. - erik
Re: [9fans] Interested in improving networking in Plan 9
I see your point. It does sound like zeroconf would be useful to some people. I wonder if it could be done with a 9p orientation as eric suggested. I don't recall what the security issues are with zeroconf, but, if it's the microsoft-inspired version I'm thinking of, I would guess there are many. I wonder if Plan 9 could provide some angle to make it more secure? Anyway, I did not mean to discourage your enthusiasm; go for it and let us know what we can do to help. ron
Re: [9fans] Interested in improving networking in Plan 9
On Sun Aug 30 14:37:29 EDT 2009, rminn...@gmail.com wrote: One way to make this kind of interesting is to address how you'd do a reasonable zeroconf effort given that you need to boot 1m+ machines. We've booted 4400*250 VMs on a machine at sandia, and, let me tell you, it was a pain. It is amusing to watch the programs traverse million line /etc/hosts file -- for a while. how does this apply to plan 9? ndb already provides for indexed databases. but i have not tried this with millions of entries. - erik
Re: [9fans] Interested in improving networking in Plan 9
Reposting this to 9fans: hola, First of all, I'm really glad you are considering Plan 9 for your project, thanks. Can someone please discuss with me how to proceed, and what are the things I should learn before starting on this ? you can start by reading nemo's intro Introduction to Operating Systems Abstractions Using Plan 9 from Bell Labs which covers pretty much everything you need to get started plus some advanced topics like how to implement a synthetic fileserver and others. http://lsub.org/who/nemo/9.intro.pdf if you need any specific help, feel free to get in touch with me. -- Federico G. Benavento
Re: [9fans] Interested in improving networking in Plan 9
On Mon, Aug 31, 2009 at 9:47 AM, Federico G. Benaventobenave...@gmail.com wrote: Reposting this to 9fans: hola, First of all, I'm really glad you are considering Plan 9 for your project, thanks. Can someone please discuss with me how to proceed, and what are the things I should learn before starting on this ? you can start by reading nemo's intro Introduction to Operating Systems Abstractions Using Plan 9 from Bell Labs which covers pretty much everything you need to get started plus some advanced topics like how to implement a synthetic fileserver and others. http://lsub.org/who/nemo/9.intro.pdf Thank you, I am going through Plan 9 from Bell Labs and The Organization of Networks in Plan 9 right now. if you need any specific help, feel free to get in touch with me. Will do ! -- Federico G. Benavento
