Re: [9fans] Blocks in C
On Thu, 2009-09-17 at 17:02 -0400, erik quanstrom wrote: ... In case anyone is wondering what they could be doing instead of feeding this massive thread more fatty foods. there's lots of complaining on the list about the content of the list. it's not like there aren't good meaty issues to discuss. what happened with either of the recently-reported fossil lockup problems, for instance? i mentioned that the pool library can act as a big kernel lock a few weeks ago. i don't know if anyone has thoughts on how to deal with this. it seems to me we deserve the list we create. I think you're right. Perhaps different folks are approaching 9fans with different assumptions, though. I see 3 camps present: 1. The actual *developers* of the technology related to Plan 9. That would include you, Russ, Inferno folks and perhaps Nemo co. 2. The actual users of Plan9. 3. The folks who do not use Plan9 in day-to-day life, but are fundamentally convinced in a WWP9D (what would Plan 9 do) principle. And, of course, there are also trolls. Trolls, aside, it looks like #1 and #2 might be slightly misaligned with #3. At least my personal experience of getting frustrated on 9fans comes mostly from the cases where I didn't positioned my question as the WWP9D one. It would be easy to say that list should be divided, in practice though, I'm not sure the folks who I would like to have a privilege of addressing would voluntarily subscribe to the #3 type of list. Thanks, Roman.
Re: [9fans] Blocks in C
On Thu, 2009-09-03 at 17:32 +0200, Uriel wrote: So libthread must be a figment of 9fan's imagination... Of course, for Apple (or anyone else) to learn from Plan 9 would be impossible, so instead they had to add a new 'feature' to C. Plan 9 has a lot to offer and a lot for others to learn from. Concurrency framework that could scale up to 1K [virtual]cores in an SMP configuration is not one of those features though. Thanks, Roman.
Re: [9fans] Blocks in C
On Thu, 2009-09-03 at 08:44 -0700, David Leimbach wrote: The blocks aren't interesting at all by themselves, I totally agree with that. However what they do to let you write a function inline, that can be pushed to another function, to be executed on a concurrent FIFO, is where the real power comes out. I'm not 100% sure why the heck they did it this way, which is totally different from any other version of concurrent programming setup I've seen, except maybe that Apple likes to think different? It seems that quite a few concurrency frameworks worth the paper their APIs are written on, are converging on this model. The ultimate goal has to do with encapsulation of the computation into idempotent units and describing the topology between those units. That separates the executor from the semantics of computations nicely and has all sorts of bonuses as far as bridging the gap between SMP and distributes systems are concerned. I think the semantics of what needs to be done is well understood. The million dollar question is how to best express such a semantics in what still looks like a programming language. What Apple has done is one way of attacking the problem. Where I sit we explore CPS for doing very similar sort of thing. One point is clear -- there no consensus yet. Thanks, Roman.
Re: [9fans] Blocks in C
On Thu, 2009-09-03 at 11:54 -0400, erik quanstrom wrote: Plan 9 has a lot to offer and a lot for others to learn from. Concurrency framework that could scale up to 1K [virtual]cores in an SMP configuration is not one of those features though. forgive the ignorance, but is there any such thing as a 1k-core smp machine? I put virtual there on purpose. Here's what I can publically share: http://www.tgdaily.com/content/view/43776/135/ and there's more to come. On a public front it is still 512 not 1K, though: 4 cpus per box * 16 physical cores per cpu * 8 virtual threads per core and is apple doing such a thing? Nobody knows what Apple is doing for sure. I know 3 things though: 1. Apple badly wants a share of a server market 2. Apple is still doing POWER, though not releasing it (just like they did x86 for 7 or so years without telling anyone) 3. POWER is getting to 1K SMP as well. even commodity intel and amd mp offerings are numa. they're not very n, but they're still n. True. But even for those platforms good SMP frameworks are quite difficult to come by. And here I do mean computation, not how to accommodate scalable IO. Thanks, Roman.
Re: [9fans] Blocks in C
On Thu, 2009-09-03 at 15:36 -0400, erik quanstrom wrote: Apple's using it all over the place in Snow Leopard, in all their native apps to write cleaner, less manual-lock code. At least, that's the claim :-). could someone explain this to me? i'm just missing how naming a block of code could change its locking properties. The explanation is in the manual I linked to earlier in this discussion. If you want to see examples there's two I can think of available for download. One is called DispatchLife the other is DispatchFractal. I've looked at DispatchLife, and there's no explicit locking of state for every cell being concurrently update in Conway's game of life. i can't find DispatchLife after a few minutes of googling. i've read the manual, and it looks like csp to me. clearly i am a reprobate outside the apple reality distortion field. could you explain why this isn't csp Please define what is it that you refer to as csp. The reason I'm asking is simple: csp-like things are needed but *not* sufficient for implementing a nice abstraction for the parallel framework. and why this can't be done with regular c (that is why we need the concept of an unnamed function pointer) and the thread library? Anything can be done using regular C and threads. The trick here is to make everything *scalable* and *painless* enough so that mere mortals can start benefiting from parallelism in their code. The other trick here is to find a model that makes things *natural*, and that means practically no explicit locking, less shared state, etc. The search for the model is meaningless unless it is used for solving *practical* challenges. In that respect, one of my favorite article is how implementation of a chess engine influenced Cilk framework (which almost has the notion of a block) http://supertech.csail.mit.edu/papers/icca99.pdf Read it, I don't think we can be on the same page (and escape the armchair philosophy trap) unless we are talking about practical applications of the framework. Look at the chess example -- can the same be done with pure C? Sure! Did Cilk make it less painful? Absolutely! Thanks, Roman.
Re: [9fans] Blocks in C
On Thu, 2009-09-03 at 17:35 -0400, erik quanstrom wrote: On Thu Sep 3 17:09:01 EDT 2009, r...@sun.com wrote: Anything can be done using regular C and threads. The trick here is to make everything *scalable* and *painless* enough so that mere mortals can start benefiting from parallelism in their code. The other trick here is to find a model that makes things *natural*, and that means practically no explicit locking, less shared state, etc. The search for the model is meaningless unless it is used for solving *practical* challenges. In that respect, one of my favorite article is how implementation of a chess engine influenced Cilk framework (which almost has the notion of a block) http://supertech.csail.mit.edu/papers/icca99.pdf Read it, I don't think we can be on the same page (and escape the armchair philosophy trap) unless we are talking about practical applications of the framework. Look at the chess example -- can the same be done with pure C? Sure! Did Cilk make it less painful? Absolutely! my question was, what's naming your function pointers or not got to do with locking? i'm asking about the language construct, not the library er i mean framework and maybe runtime that goes with it. It has nothing to do with locking. You are correct. However, the style of programming that it allows lets you build lock-free computations much more *elegantly*. I use the word elegantly on purpose here. Since the discussion is already in the personal taste territory all I can do to back my claim is to note that regardless of whether blocks are closures or not (they are not) they are true lambdas. Are lambdas useful? I sure think so, but I don't think I can convince you by any other means except for offering links to LAMBDA the ultimate... set of articles: http://library.readscheme.org/page1.html Thanks, Roman.
[9fans] Petabytes on a budget: JBODs + Linux + JFS
None of those technologies [NFS, iSCSI, FC] scales as cheaply, reliably, goes as big, nor can be managed as easily as stand-alone pods with their own IP address waiting for requests on HTTPS. http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-how-to-build-cheap-cloud-storage/ Apart from the obvious comment that I swear I used a quote like that to justify 9P more than once, I'm very curious to know how Plan9 would perform on such a box. Erik, do you have any comments? Thanks, Roman.
Re: [9fans] Blocks in C
On Thu, 2009-09-03 at 12:44 -0400, erik quanstrom wrote: On Thu Sep 3 12:20:09 EDT 2009, r...@sun.com wrote: On Thu, 2009-09-03 at 11:54 -0400, erik quanstrom wrote: Plan 9 has a lot to offer and a lot for others to learn from. Concurrency framework that could scale up to 1K [virtual]cores in an SMP configuration is not one of those features though. forgive the ignorance, but is there any such thing as a 1k-core smp machine? [...] True. But even for those platforms good SMP frameworks are quite difficult to come by. And here I do mean computation, not how to accommodate scalable IO. i'll grant you this in implementation. the pool library's lock in effect becomes plan 9's BLK. since the pool library is used in the kernel and user space, a user space application gets hit twice. i've been doing some full-tilt boogie testing with 2x10gbe and even with 2 cores, the BLK^wpool lock is devastating. I'm not surprised here. I'm also not surprised that it gets used twice -- that's precisely what Sun does with slab allocator. where do you see the theoretical limitation in plan 9? I don't think there's anything limiting plan 9, except for people willing to invest their time and coding skills in tuning these things and coming up with programming frameworks that take us further than manually juggling processes/threads. My view is a bit skewed towards computations, and there its all about your kernel scheduler and memory usage patterns. At least at the low level it is. So I guess as long as these things are ok, you can then build abstractions a'la GCD on top of them. Thanks, Roman.
Re: [9fans] Blocks in C
On Wed, 2009-09-02 at 10:04 +0200, Anant Narayanan wrote:
Mac OS 10.6 introduced a new C compiler frontend (clang), which added
support for blocks in C [1]. Blocks basically add closures and
anonymous functions to C (and it's derivatives).
They are NOT closures in my book. They lack lexical scoping. A true
closure makes the following possible (using JavaScript to stay closer
to C syntax):
function outer() {
var outer_var = 1;
return function () {
outer_var = { simply: a different object }
}
}
Notice how I can modify outer_var from within the closure. With blocks
all you get is an upvaluer (IOW, outer_var becomes constant).
This is still useful for things like map, etc. But I hate when people
call anonymous classes in Java closures (although depending on
a textbook it is possible to stretch the term).
Finally, if you want to know how to get from GCC blocks to the real
deal read up 6.6 of this excellent paper:
http://www.lua.org/doc/hopl.pdf
Full details with examples are in the linked article.
The article seems to miss a couple of important points. And the
better alternative for those who want to know what's going on
is Apple's developer website:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Blocks/Articles/00_Introduction.html#//apple_ref/doc/uid/TP40007502-CH1-SW1
I think the feature is quite
elegant and might be useful in cases where you want map/reduce like
functionality in C.
It is a fun feature, no doubt. It is also pretty easy to implement.
How much effort would it be to support a feature similar to blocks in
8c (and family)? What are your thoughts on the idea in general?
Personally I think you'd be better off exploring a connection that a
language called Lua has to C. In the immortal words of Casablanca it
just could be the begging of a beautiful friendship.
Thanks,
Roman.
Re: [9fans] Blocks in C
On Wed, 2009-09-02 at 08:07 -0700, David Leimbach wrote: Has anyone actually looked at the spec Yes. Well, I know I did ;-) I've actually looked at these, and used em a little bit. They're not at all as bad as I once thought they could be, and the reason they're there is to work with a concurrency framework onto which blocks can be scheduled to run on various queues, to do concurrent programming. Right-O. In fact, blocks are particularly, how shall I put it, congruent to the most promising C parallelization framework to date: Cilk. Does it succeed in the goal of making it possible to do lockless programming of concurrent applications? Yes, there's several rather interesting examples showing the concurrent computation of all the cells in Conway's Life for example. I'd say this beats the snot out of coding with pthreads. One again, have you tried Cilk for exactly this kind of thing? I'd be curious to know your opinion on how what you see in SL compares to it. Blocks themselves are really not terribly useful, you need the libdispatch library to make the real value in them come out, which does all the queue management by talking to the subsystem of Snow Leopard called Grand Central Dispatch. Could you, please, send me a pointer to the API docs? Off list, perhaps? Thanks, Roman.
Re: [9fans] nice quote
On Wed, 2009-09-02 at 12:11 -0700, Brian L. Stuart wrote: Q: Will C continue to be important into the future? (Dave Kirk, Nvidia)A: No, I think C will die like Fortran has let me explain the joke. In HPC circles, people have been predicting the death of fortran for 30 years. Fortran has continued to grow and thrive. The predictions continue, but the latest fortran standard includes objects. So, what Dave is saying, tongue in cheek, is that C will die in the way fortran has -- i.e., not at all. I just hope standards committees don't enhance C into Frankenstein's monster. A friend of mine, who is still serving on the C committee, once mentioned who lucky they were to have C++ around as a perfect dumping ground for all the cool enhancements that got proposed along the way. Thanks, Roman. P.S. Another friend of mine still feels sad that Fortress didn't become that same sort of dumping ground for Fortran ;-)
Re: [9fans] iwp9 deadline extension
On Fri, 2009-08-28 at 16:11 -0400, Devon H. O'Dell wrote: 2009/8/28 Eric Van Hensbergen eri...@gmail.com: Satelite conference locations in Antwerp and Oz may be be a bad idea assuming folks can accomodate crazy time differences. Not a bad idea, does anyone on the else pc have A/V equipment? I do, but it's not great stuff (just webcam quality), so it'd be like last resort stuff. I could get a DV cam if necessary. I have a semi-pro DV cam (which is a life safer in poor lighting conditions) which I can bring. Streaming should not really be a problem given that our viewership is likely to be in 2 digits. Thanks, Roman.
Re: [9fans] 9P on android
On Thu, 2009-08-27 at 10:24 -0700, Skip Tavakkolian wrote: because there can only be one outstanding request -- with continuous polling. Unless I misunderstood you, this is not quite true. You can have as many outstanding requests as you have XMLHTTPRequest objects. And, of course, you can do AJAX Push using various techniques. So it really is not all that different, except that you have to strip the HTTP envelope. Thanks, Roman.
[9fans] [Fwd: Mentor Summit - Dates Confirmed, Holding Pattern for Now (longish but important)]
Datewise this looks like a pretty good potential for continuation of the IWP9 '09 ;-) Thanks, Roman. ---BeginMessage--- Hello everyone, We have confirmed that we'll hold our annual mentor summit on the 24 25 October this year at the Googleplex in Mountain View, California. Assume we will also have the pre-summit festivities on the evening of the 23rd for locals and those who arrive in town early and are not eaten by jet lag. As usual, we will be inviting mentoring organizations to send 2 mentors and will make more room for locals who do not require travel assistance based on space. In other words, we will be keeping a wait list for local folks again and opening up room for folks on the wait list as we get closer to the event. We have not yet determined the following: - which organizations will be invited (but it's looking good for all 150 from this year so far) - how much funding will be provided for travel assistance to each organization - which hotel we will be using, domain vs. wild palms vs. both - what meals we will be serving - summit hours - schedule of sessions during summit hours So as you can see, beyond the dates we haven't determined much of anything. Really, that's OK, as we have two months to figure all that out and for all of you to buy your plane tickets. What I'd like to ask now is that all you folks to talk amongst yourselves to determine who would be best served by representing your organization at the summit. If you have never been to a summit, please check out the wiki [0] and search the archives of this list for more data. Those of you who would like to share a bit about summits past, please do so in this thread. For those who would rather not hear the discussion, please mute/ autoarchive/otherwise filter. If one of you would like to start a page on the wiki for the 2009 summit to begin capturing session ideas and all that jazz. If someone would like to also copy over the basic content like location (Googleplex!), airport info, etc and let folks know that is done, we could begin updating it with our collective wisdom (like the fact that a limo is now cheaper than a cab from SFO - eek!). So for now, holding pattern. More info after 1 September, but perhaps a week or two after that, so patience please. Cheers, LH [0] - https://gsoc-wiki.osuosl.org/index.php/Main_Page username - mentor password - yourock --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Summer of Code Mentors List group. To post to this group, send email to google-summer-of-code-mentors-l...@googlegroups.com To unsubscribe from this group, send email to google-summer-of-code-mentors-list+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-summer-of-code-mentors-list?hl=en -~--~~~~--~~--~--~--- ---End Message---
[9fans] Lua on Plan9
On Fri, 2009-08-14 at 09:16 +, Pavel Klinkovsky wrote: Speaking of which (or may be not ;-)) is there anybody using Lua on Plan9? I am playing with Lua on my Plan9 computer... What do you use it for? Any kind of fun projects? My idea is to try and see whether Plan9+Lua would be a more useful combination for building Web service environment than werc. Thanks, Roman.
[9fans] Lua on Plan9
On Fri, 2009-08-14 at 09:27 +0100, Robert Raschke wrote: Last time I tried, the standard Lua compiled out of the box under the APE. That is good to know. Still, I'd rather see it run without APE. Great little language. I use it in my day job (together with Erlang). *together* with Erlang?!?! That I have to know more about. Perhaps off-list. It's implementation is indeed just as enlightening as the Plan 9 code. An exercise in doing exactly what is required and no more. Very elegant in my eyes. Couldn't agree more! Thanks, Roman.
Re: [9fans] Using proportional fonts in Acme for Programming
On Fri, 2009-08-14 at 10:49 -0600, Daniel Lyons wrote: On Aug 14, 2009, at 3:15 AM, Aaron W. Hsu wrote: On Thu, 13 Aug 2009 13:58:39 -0400, Daniel Lyons fus...@storytotell.org wrote: I'd love it if Acme or Plan 9 had good support for some kind of Lisp variant. Maybe that should be my next side project. If that's something you're thinking about doing, let me suggest you take a look at Clojure. The Java aspect aside, it is a good compromise in design between Scheme and Lisp and introduces lots of good ideas. This is something I would want to do but I have a long way to go with Plan 9 before I think I could be serious about it. I looked at it for a while and came with a realization that it could be just a tad heavier than what I need for most of the stuff I do. Plus I'm not sure how to port it to Plan9 without first porting the JVM. Thanks, Roman.
Re: [9fans] Thrift RPC
On Thu, 2009-08-13 at 09:42 +0100, roger peppe wrote:
2009/8/13 Roman Shaposhnik r...@sun.com:
Am I totally missing something or hasn't been the binary RPC
of that style been dead ever since SUNRPC? Hasn't the eulogy
been delivered by CORBA? Haven't folks realized that S-exprs
are really quite good for data serialization in the heterogeneous
environments (especially when they are called JSON)
i'm not familiar with Thrift, but i've done some stuff with google protobufs,
from which i think Thrift is inspired.
I'd be very curious to know the details of the project where you
did find protobufs useful. Can you share, please?
speaking of protobufs, i don't think they're a bad idea.
they're specifically designed to deal
with forward- and backward-compatibility, which is something
you don't automatically get with s-expressions,
Not unless you can make transport protocol take care of that for you.
HTTP most certainly can and same can be said about 9P. I truly believe
that such a division of labor is a good thing. Thrift and protobufs are
doing RPC, I think we can agree on that. So if we were to look at how
local procedure calls are dealing with the compatibility issue we get
dynamic linker symbol versioning. I don't like those, but at least they
are implemented in the right place -- the dynamic linker. What Thrift
feels like would be analogous to pushing that machinery into my
library.
And since we are on this subject of dynamic linking -- one of the
fallacies of introducing versioning was that it would somehow make
compatibility seamless. It didn't. In all practical cases it made things
much, much, much worse. Perhaps web services are different, but I can't
really pinpoint what makes them so: you are doing calls to the symbols,
the symbols are versioned and they also happen to be remote. Not much
difference from calling your trustworthy r...@version1 ;-)
and if you're
dealing with many identically-typed records, the fact that each field
in each record is not string-tagged counts saves a lot of bandwidth
(and makes them more compressible, too).
That's really a type of YMMV argument. I can only speak from my personal
experience where the latency is much more a problem than bandwidth.
we don't use text for 9p, do we?
No we don't. But, as erik pointed out we use 9P as a transport
protocol. My biggest beef with how Thrift was positioned (and
that's why I'm so curious to know the details of your project)
is the fact that they seem to be pushing it as a better JSON.
At that level -- you already have a transport protocol, and
it just doesn't make a lot of sense to represent data in such
an unfriendly manner. And representation is important. After all,
REST stands for *representational* state transfer, doesn't it?
I certainly wouldn't object to Thrift use as a poorman's way
of implementing an equivalent of 9P (or any kind of protocol
for that matter) cheaply.
Hm. Now that I've mentioned it, perhaps trying Thrift out as
an implementation mechanism for 9P and comparing the result
with the handwritten stuff would be a good way for me to
really see how useful it might be in practice.
and you
really shouldn't be made to figure out how large is the integer
on a host foo?
I firmly believe in self-descriptive data. If you have an integer
you have an integer. You shouldn't burden the representation layer
with encoding issues. Thus:
{ integer: 12312321...very long stream of digits...123123 }
is a perfectly good way to send the data. You might unpack it
into whatever makes sense on the receiving end, but please don't
make me suffer at the data representation layer.
Thanks,
Roman.
Re: [9fans] audio standards -- too many to choose from
On Wed, 2009-08-12 at 17:36 +0200, hiro wrote: This sounds like exactly the kind of thing one wants from an audio driver for playback. For recording things get slightly more complicated. What exactly do you mean? Now that I understand what Tim is trying to do my original concern makes no sense. Sorry for this little bit of noise. Even for playback if you want to do passthrough (via SPDIF or some such) things get slightly more complicated. Of course, one can disregard passthrough as not being an audio at all, but rather a datalink issue. What's so special about things like SPDIF? Two things: the data traveling over the link can be any data, not just some form of PCM (it can be AC-3, it can be DTS, it can even be MP3). In that respect the audio card acts as a pass-through device. It is not really supposed to do anything with the data. And that brings us to the second point -- the pass-through APIs can be as ugly as hell, depending on the type of the device (follow the link to the MPlayer docs I provided in this thread). Why would it be not suitible for the kernel audio driver? Because it has very little to do with the PCM audio, and that's what the driver discussed in this thread was supposed to be all about. Now, I'm not saying that there's shouldn't be a special driver just for pass-through type of functionality, all I'm saying is that lumping this functionality together with the PCM one would confuse things. For me it's clearly an audio and not a datalink issue, but perhaps I have only limited use cases. Perhaps, everywhere in this thread I should've prefixed the word audio with some form of PCM. Thanks, Roman.
Re: [9fans] Using proportional fonts in Acme for Programming
On Thu, 2009-08-13 at 11:55 -0600, Daniel Lyons wrote: I'd love it if Acme or Plan 9 had good support for some kind of Lisp variant. Speaking of which (or may be not ;-)) is there anybody using Lua on Plan9? Thanks, Roman. P.S. The more I look into Lua (as a way to help C refuge start doing some functional stuff) the more it seems that the two have a lot in common when it comes to software architecture.
Re: [9fans] ceph
On Mon, 2009-08-03 at 19:56 -0700, ron minnich wrote: 2. do we have anybody successfully managing that much storage that is also spread across the nodes? And if so, what's the best practices out there to make the client not worry about where does the storage actually come from (IOW, any kind of proxying of I/O, etc) Google? By we I mostly meant this community, but even if we don't focus on 9fans, Google is a non-example. They have no clients for this filesystem per-se. The request: for each of the (lots of) compute nodes, have them mount over 9p to, say 100x fewer io nodes, each of those to run lustre. Sorry for being dense, but what exactly is going to be accomplished by proxying I/O in such a way? it makes the unscalable distributed lock manager and other such stuff work, because you stop asking it to scale. So strictly speaking you are not really using 9P as a filesystem protocol, but rather as a convenient way for doing RPC, right? Thanks, Roman.
Re: [9fans] ceph
On Tue, 2009-08-04 at 10:55 +0100, C H Forsyth wrote: they emphatically don't go for posix semantics... what are posix semantics? I'll bite: http://www.opengroup.org/onlinepubs/009695399/ [ anything else that would take an FD as an argument ] http://www.opengroup.org/onlinepubs/009695399/ Thanks, Roman.
Re: [9fans] ceph
On Tue, 2009-08-04 at 09:43 +0100, Steve Simon wrote: Well, with Linux, at least you have a benefit of a gazillions of FS clients being available either natively or via FUSE. Do you have a link to a site which lists interesting FUSE filesystems, I am definitely not trying to troll, I am always intrigued by others ideas of how to reprisent data/APIs as fs. I don't, and I probably should start documenting it. The easiest way to find them, though, is to be suscbribed to fuse ML and collect the domain names of posters. Turns out that anybody who's doing cloud storage these days does it via FUSE (which, might not be as surprising if you think about what's the dominant OS on EC2). You have companies ranging from startups: http://www.nirvanix.com/ all the way to tyrannosaurus' like EMC and IBM betting on FUSE to get them to storage in the cloud. Sadly, none of them are open source as far as I can tell. Sadly the Fuse fs I have seen have mostly been disappointing.There are a few I which would be handy on plan9 (gmail, ipod, svn) but most seem less useful. The OS ones, are not all that impressive. I agree. Thanks, Roman.
Re: [9fans] ceph
On Mon, 2009-08-03 at 21:23 -1000, Tim Newsham wrote: 2. do we have anybody successfully managing that much storage that is also spread across the nodes? And if so, what's the best practices out there to make the client not worry about where does the storage actually come from (IOW, any kind of proxying of I/O, etc) http://labs.google.com/papers/gfs.html http://hadoop.apache.org/common/docs/current/hdfs_design.html I'm trying to see how the life after NFSv4 or AFS might look like for the clients still clinging to the old ways of doing things, yet trying to cooperatively use hundreds of T of storage. the two I mention above are both used in conjunction with distributed map/reduce calculations. Calculations are done on the nodes where the data is stored... Hadoop and GFS are good examples and they work great for the single distributed application that is *written* with them in mind. Unfortunately, I can not stretch my imagination hard enough to see them as general purpose filesystems backing up data for gazillions of non-cooperative applications. The sort of thing NFS and AFS were built to accomplish. In that respect, ceph is more what I have in mind: it assembles storage from clusters of unrelated OSDs into a a hierarchy with a single point of entry for every user/application. The question, however, is how to avoid the complexity of ceph and still have it look like a humongous kenfs or fossil from the outside. Thanks, Roman.
Re: [9fans] Intel atom motherboard - success at last
On Tue, 2009-08-04 at 19:33 -0400, erik quanstrom wrote: Steve, can you list the total configuration of this machine... motherboard model etc? This sounds a lot like what I was thinking of building for home. I also would like to try Erik's new ISO, but sadly, haven't had a lot of free time to do anything with it. (I already downloaded it) http://www.supermicro.com/products/motherboard/ATOM/945/X7SLA.cfm?typ=H vesa graphics are quite snappy, though it's a shame to give up the second processor. This one still has a fan. Is there anything decent *and* fanless out there? Thanks, Roman.
[9fans] renaming to an existing file
I've just realized that in 9P the wstat would refuse to rename an entry if a target name already exists. So how can I atomically replace one file with another one, so that during the operation clients opening it would not fail? In POSIX rename gives you such an atomicity: --- If the old argument points to the pathname of a file that is not a directory, the new argument shall not point to the pathname of a directory. If the link named by the new argument exists, it shall be removed and old renamed to new. In this case, a link named new shall remain visible to other processes throughout the renaming operation and refer either to the file referred to by new or old before the operation began. How can I achieve the same result with 9P? Thanks, Roman.
Re: [9fans] ceph
On Sat, 2009-08-01 at 08:47 -0700, ron minnich wrote: What are their requirements as far as POSIX is concerned? 10,000 machines, working on a single app, must have access to a common file store with full posix semantics and it all has to work like it were one machine (their desktop, of course). This gets messy. It turns into an exercise of attempting to manage a competing set of race conditions. It's like tuning a multi-carburated enging from years gone by, assuming we ever had an engine with 10,000 cylinders. Well, with Linux, at least you have a benefit of a gazillions of FS clients being available either natively or via FUSE. With Solaris... oh well... How much storage are talking about? In round numbers, for the small clusters, usually a couple hundred T. For anyhing else, more. Is all of this storage attached to a very small number of IO nodes, or is it evenly spread across the cluster? In fact, I'm interested in both scenarios, so here come two questions: 1. do we have anybody successfully managing that much storage (lets say ~100T) via something like humongous fossil installation (or kenfs for that matter)? 2. do we have anybody successfully managing that much storage that is also spread across the nodes? And if so, what's the best practices out there to make the client not worry about where does the storage actually come from (IOW, any kind of proxying of I/O, etc) I'm trying to see how the life after NFSv4 or AFS might look like for the clients still clinging to the old ways of doing things, yet trying to cooperatively use hundreds of T of storage. I'd be interested in discussing some aspects of what you're trying to accomplish with 9P for the HPC guys. The request: for each of the (lots of) compute nodes, have them mount over 9p to, say 100x fewer io nodes, each of those to run lustre. Sorry for being dense, but what exactly is going to be accomplished by proxying I/O in such a way? Thanks, Roman.
[9fans] ceph
This is sort of off-topic, but does anybody have any experience with Ceph? http://ceph.newdream.net/ Good or bad war stories (and general thoughts) would be quite welcome. Thanks, Roman.
Re: [9fans] i/o on a hangup channel asymmetry
On Mon, 2009-07-20 at 01:21 -0400, erik quanstrom wrote:
one last kick of a dead horse: see that's exactly what I'm
talking about -- all these exceptions and for what? I'm
pretty sure if we change the devpipe today not to send
a note nobody would even notice...
since you're confident that this exception is spurious,
why don't you remove it from your kernel? your
argument would be much more convincing if you had
evidence that after a couple million pids, your cpu
server has experienced no funnies.
This does look like a curious experiment. Now, since I don't
run a native Plan9 kernel, I did modify 9vx (one can't thank
Russ enough for providing it!):
--- a/src/9vx/a/devpipe.c
+++ b/src/9vx/a/devpipe.c
@@ -313,8 +313,9 @@ pipewrite(Chan *c, void *va, long n, vlong offset)
print(pipewrite hi %lux\n, getcallerpc(c));
if(waserror()) {
/* avoid notes when pipe is a mounted queue */
- if((c-flag CMSG) == 0)
+ /* if((c-flag CMSG) == 0)
postnote(up, 1, sys: write on closed pipe, NUser);
+*/
nexterror();
}
@@ -345,8 +346,9 @@ pipebwrite(Chan *c, Block *bp, ulong offset)
if(waserror()) {
/* avoid notes when pipe is a mounted queue */
- if((c-flag CMSG) == 0)
+ /* if((c-flag CMSG) == 0)
postnote(up, 1, sys: write on closed pipe, NUser);
+*/
nexterror();
}
So far so good. The test2.c now returns -1 i/o on a hangup channel from write
and the rest of the system seems to be pretty stable.
The usual pipelines that I run (ls | sort, ...|awk, ...|sed) all seem to
be doing quite well.
Unfortunately I don't think I can get to a couple of million pids in my
9vx as you've suggested. So I guess, in the end, it doesn't count,
right?
Thanks,
Roman.
Re: [9fans] i/o on a hangup channel asymmetry
On Mon, 2009-07-20 at 10:53 +0100, Charles Forsyth wrote: pipe would return -1 (and set a error condition) and the applications were paying attention (and I'm pretty sure all applications on Plan 9 would do a reasonable thing when presented with -1 from a write). they only notice when the write occurs. suppose that takes several minutes of computation. Just to correct the statement of fact: same as true for the note -- it only gets sent when the write occurs. Thus -- there's no difference, really. Thanks, Roman.
Re: [9fans] i/o on a hangup channel asymmetry
On Mon, 2009-07-20 at 10:52 +0100, Charles Forsyth wrote:
you don't really want to get write error printed from every
process in a pipe line such as
As much as I thought that could be an issue, I could NOT actually
make many of the commands I tried produce this message on a
modified 9vx:
term% ls | date
Some did produce a message, but somehow it didn't look all that
problematic (helpful, in fact -- letting me know that somewhere
in my pipe there was a problem and not all of the data went through):
term% awk 'BEGIN { printf(Hello\n); }' | date
awk: write error on stdout
slowly-compute-big-file | dosomemore | andyetmore | sed -n
'/something/;p;q'
or even
slowly-compute-big-file | badusageofsomething
where the latter prints a usage message and quits.
you want to make sure the previous commands in the pipeline stop, right away.
One again -- just to make things clear -- slowly-compute-big-file WILL
NOT stop before it attempts the first actual write on a closed pipe. It
will merrily compute away. A trivial:
cpu% sleep 100 | sleep 1
would be enough to verify your hypothesis.
Thanks,
Roman.
Re: [9fans] git on plan9
On Mon, 2009-07-20 at 14:39 -0700, John Floren wrote: Hi Can I get a copy of your code? In fact, can it put in contrib ? Thanks, Roman. Thanks John On Sat, Jul 18, 2009 at 3:46 PM, driv...@0xabadba.be wrote: Phew finally got it. There was some hackery involved in the hg-git python code since mmap wasn't supported -- i basically just implemented them with reads; however I was considering writing an mmap module that used reads but realized that would be misleading since it wasn't really mmap. I think altering the hg-git code is the best option and i've done it in such a way that its isolated so it can be easily updated from mainstream. Let me know if you want it. ++james rator_gade% hg clone git://zen-sources.org/zen/THE.git destination directory: THE.git fetching from : git://zen-sources.org/zen/THE.git importing Hg objects into Git Counting objects: 1592, done. Compressing objects: 0% (1/1185) Compressing objects: 1% (12/1185) Compressing objects: 2% (24/1185) Compressing objects: 3% (36/1185) Compressing objects: 4% (48/1185) Compressing objects: 5% (60/1185) Compressing objects: 6% (72/1185) Compressing objects: 7% (83/1185) Compressing objects: 8% (95/1185) Compressing objects: 9% (107/1185) Compressing objects: 10% (119/1185) Compressing objects: 11% (131/1185) Compressing objects: 12% (143/1185) Compressing objects: 13% (155/1185) Compressing objects: 14% (166/1185) Compressing objects: 15% (178/1185) Compressing objects: 16% (190/1185) Compressing objects: 17% (202/1185) Compressing objects: 18% (214/1185) Compressing objects: 19% (226/1185) Compressing objects: 20% (237/1185) Compressing objects: 21% (249/1185) Compressing objects: 22% (261/1185) Compressing objects: 23% (273/1185) Compressing objects: 24% (285/1185) Compressing objects: 25% (297/1185) Compressing objects: 26% (309/1185) Compressing objects: 27% (320/1185) Compressing objects: 28% (332/1185) Compressing objects: 29% (344/1185) Compressing objects: 30% (356/1185) Compressing objects: 31% (368/1185) Compressing objects: 32% (380/1185) Compressing objects: 33% (392/1185) Compressing objects: 34% (403/1185) Compressing objects: 35% (415/1185) Compressing objects: 36% (427/1185) Compressing objects: 37% (439/1185) Compressing objects: 38% (451/1185) Compressing objects: 39% (463/1185) Compressing objects: 40% (474/1185) Compressing objects: 41% (486/1185) Compressing objects: 42% (498/1185) Compressing objects: 43% (510/1185) Compressing objects: 44% (522/1185) Compressing objects: 45% (534/1185) Compressing objects: 46% (546/1185) Compressing objects: 47% (557/1185) Compressing objects: 48% (569/1185) Compressing objects: 49% (581/1185) Compressing objects: 50% (593/1185) Compressing objects: 51% (605/1185) Compressing objects: 52% (617/1185) Compressing objects: 53% (629/1185) Compressing objects: 54% (640/1185) Compressing objects: 55% (652/1185) Compressing objects: 56% (664/1185) Compressing objects: 57% (676/1185) Compressing objects: 58% (688/1185) Compressing objects: 59% (700/1185) Compressing objects: 60% (711/1185) Compressing objects: 61% (723/1185) Compressing objects: 62% (735/1185) Compressing objects: 63% (747/1185) Compressing objects: 64% (759/1185) Compressing objects: 65% (771/1185) Compressing objects: 66% (783/1185) Compressing objects: 67% (794/1185) Compressing objects: 68% (806/1185) Compressing objects: 69% (818/1185) Compressing objects: 70% (830/1185) Compressing objects: 71% (842/1185) Compressing objects: 72% (854/1185) Compressing objects: 73% (866/1185) Compressing objects: 74% (877/1185) Compressing objects: 75% (889/1185) Compressing objects: 76% (901/1185) Compressing objects: 77% (913/1185) Compressing objects: 78% (925/1185) Compressing objects: 79% (937/1185) Compressing objects: 80% (948/1185) Compressing objects: 81% (960/1185) Compressing objects: 82% (972/1185) Compressing objects: 83% (984/1185) Compressing objects: 84% (996/1185) Compressing objects: 85% (1008/1185) Compressing objects: 86% (1020/1185) Compressing objects: 87% (1031/1185) Compressing objects: 88% (1043/1185) Compressing objects: 89% (1055/1185) Compressing objects: 90% (1067/1185) Compressing objects: 91% (1079/1185) Compressing objects: 92% (1091/1185) Compressing objects: 93% (1103/1185) Compressing objects: 94% (1114/1185) Compressing objects: 95% (1126/1185) Compressing objects: 96% (1138/1185) Compressing objects: 97% (1150/1185) Compressing objects: 98% (1162/1185) Compressing objects: 99% (1174/1185) Compressing objects: 100% (1185/1185) Compressing objects: 100% (1185/1185), done. Total 1592 (delta 455), reused 1128 (delta 286) importing Git
[9fans] i/o on a hangup channel asymmetry
In the mom, why sky is blue department, here's a silly question: is there any good reason that read(2) on a hangup channel returns an error, while write(2) on a hangup channel terminates an application (by generating a note, of course, which can be ignored, but still)? Thanks, Roman. P.S. And btw, is there any way to make UNIX (POSIX) behave like Plan9 read(1)? The EOF on a hangup channel is actually misleading, its not that the channel can be ever resumed...
Re: [9fans] C compiler question
On Mon, 2009-07-13 at 23:14 -0400, erik quanstrom wrote: Yes, but in my example - sorry - NeverDefined doesn't mean declared and defined elsewhere (or not) but not declared .and. not defined. true enough. the patch i sent still rejects your construct. i'd still be interested to hear a perspective of someone with more experience with the c compiler. rejecting the struct seems like the right thing to do as per ISO/IEC 9899:1999 (http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf) sec. 6.7.2.1 para. 2 A structure or union shall not contain a member with incomplete or function type (hence, a structure shall not contain an instance of itself, but may contain a pointer to an instance of itself), except that the last member of a structure with more than one named member may have incomplete array type; such a structure (and any union containing, possibly recursively, a member that is such a structure) shall not be a member of a structure or an element of an array. Thanks, Roman.
Re: [9fans] C compiler question
On Tue, 2009-07-14 at 13:46 -0400, erik quanstrom wrote: rejecting the struct seems like the right thing to do as per ISO/IEC 9899:1999 (http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf) sec. 6.7.2.1 para. 2 A structure or union shall not contain a member with incomplete or function type (hence, a structure shall not contain an instance of itself, but may contain a pointer to an instance of itself), except that the last member of a structure with more than one named member may have incomplete array type; such a structure (and any union containing, possibly recursively, a member that is such a structure) shall not be a member of a structure or an element of an array. you're implying that the point of the plan 9 compilers is to toe the c99 line. For the dirty corner of any language one is usually better off with a written formal standard. Now, since Plan9 doesn't have such a document, relying on a work done by c99 committee would seem like a wise thing to do. And it is not like we are talking about C++ ISO standard here, the C99 is actually quite beautiful (except may be a couple of places like compound literals, and stuff). What's your problem with such an approach? also, a pointer to an incomplete type is used in many places in plan 9 libraries. The above paragraph has nothing to do with pointers to incomplete types (except for a clarification). Why are you bringing this up? Thanks, Roman.
Re: [9fans] pointers to incomplete types
On Tue, 2009-07-14 at 15:29 -0400, erik quanstrom wrote: The above paragraph has nothing to do with pointers to incomplete types (except for a clarification). Why are you bringing this up? assuming that pointers to incomplete types are themselves incomplete, and you haven't cited chapter and verse showing they are, i read that paragraph as saying that what plan 9 libraries do would be illegal, and therefore if we follow the standard, we'd need to remove Incomplete*s and replace them with void*s. if i'm wrong, can you explain how? The pointer to the incomplete type is a pointer type, not an incomplete type. It is part of the section describing tye type system of C99 (section 6.2.5). Look for derived types. Thanks, Roman.
Re: [9fans] data analysis on plan9
On Thu, 2009-07-09 at 15:56 -0300, Federico G. Benavento wrote: Also, something similar to GSL (http://www.gnu.org/software/gsl/) gsl-1.6.tbz GNU Scientific Library, native port. /n/sources/contrib/pac/sys/src/lib/gsl-1.6.tbz I've been meaning to ask this for a long time -- do we have a catalog of things in contrib? Thanks, Roman.
Re: [9fans] Different representations of the same
On Fri, 2009-06-12 at 21:56 -0400, erik quanstrom wrote: I thought you might want a ctl file into which you write the representation you want and that magically creates a new file or directory. Sure, but if *each* file can have more than one representation then where's the best place for the ctl thing to be? In each subdirectory? At the top of the hierarchy (accepting the full path names, of course)? [...] I'm simply asking for the best practices. generally, plan 9 fs pick a cannonical format if they can get away with it. the right answer is going to depend very strongly on one's exact constraints. if the client knows he's always going to want pngs, it might be good to pass png as the spec, as in ; mount /srv/media /n/media png i suppose this would be a lot like content negotiation. Exactly! From where I stand it seems that a particular representation has to be either part of the name, or it has to hide in a invisbible part of the protocol. The benefits of having representation spec being part of the name are obvious -- you are alway know what you're asking for, plus you can explicitly list representations if there's more than one. The only drawback so far seems to be the fact that if one needs flexibility, then every file becomes a subdirectory. Not that it is scary or anything, but it smells too much of resource forks (or may be I'm just too easily scared). there are some really wild examples running about. hackery in upas that will serve up x(\.$e)? for any $e in certain circumstances. (see upas/ned/nedmail.c:/^plumb.) the reason for this is so that upas/fs can serve up content with type unknown to upas/fs so that it can match plumbing rules that expect file extensions. the alternative would have been to add an explicitly declared filetype to the plumb messages and adding a ruletype to the plumb files. i suppose the idea was to not break everyone's plumbing rules. Interesting... Thanks, Roman.
Re: [9fans] porting p9p to Google's NaCl
On Fri, 2009-06-12 at 13:04 -0700, Skip Tavakkolian wrote: anyone working on this? What's so great about NaCl? Isn't it just a fancy way to start QEmu/VirtualBox/VMWare? Thanks, Roman.
Re: [9fans] Different representations of the same
On Thu, 2009-06-11 at 06:49 +0200, lu...@proxima.alt.za wrote: but at that point it becomes no more appealing than the content negotiation techniques of HTTP. I thought you might want a ctl file into which you write the representation you want and that magically creates a new file or directory. Sure, but if *each* file can have more than one representation then where's the best place for the ctl thing to be? In each subdirectory? At the top of the hierarchy (accepting the full path names, of course)? Or use a clone style protocol which is more suitable for the automatic creation of new entities. clone doesn't quite work for me in REST world (not that it can't be made to work, it is just complicated). Of course, you may specifically want to go for a totally different approach, in which case I plead guilty to not understanding the exact nature of the solution you're seeking. I'm simply asking for the best practices. Also, as I admitted in my original email, I'm not really implementing this in 9P. So I have an option that is native to the protocol I'm using: content negotiation (http://en.wikipedia.org/wiki/Content_negotiation) Now, since 9P doesn't have that I was simply wondering what would be the agreed upon wisdom to have the same functionality _cleanly_ implemented in a 9P based synthetic filesystem. Thanks, Roman.
Re: [9fans] Different representations of the same file/resource in a synthetic FS
В Втр, 09/06/2009 в 11:27 -0600, andrey mirtchovski пишет: I think I've mentioned this before, but on a few of my synthetic file systems here I'm using what you describe to slice a database by specific orderings. For example, I have a (long) list of resources which I'm managing in a particular environment each has an owner, type, status and a few static data containers. It's all backed by a relational database, but the file server presents different slices of that to external users, where the directory structure is rigidly defined as: / available/ by-type/ by-owner/ inuse/ ... with all data to fill the directories being dynamically pulled from the database. This looks like a slightly different use case than what I'm worried about. Mainly it seems that you don't really have to deal with the representations of the same resource, your problem is how to group these resources in a reasonable fashion. Essentially you're mapping a relational database to a tree hierarchy. In your case, the sooner you have the fork of by-this/ by-that/ in your hierarchy -- the better. My case is a flip side of that. In fact, my worst case scenario is that I can't really predict all the representations of existing resources down the road, thus it appears that I have to push that part of a filename as close to an actual file as possible: /long-path/file.representation I'm almost tempted to consider virtual extensions: /long-path/file ## default representation /long-path/file.gif /long-path/file.pdf but at that point it becomes no more appealing than the content negotiation techniques of HTTP. Thanks, Roman.
Re: [9fans] Configuring NFS
Hi John, it took me sometime to go through the old backups but it seems that the NFS setup is gone by now. You can still ask questions, if you want to, but I won't be able to send you all the working conf. files. On Tue, 2009-06-02 at 11:34 -0700, John Floren wrote: I'd like to use the 9p mounting available in Linux, but it doesn't seem to work in this case. I try mount -t 9p glenda /mnt (glenda is my cpu/file server) and get: mount: wrong fs type, bad option, bad superblock on glenda, missing codepage or helper program, or other error (for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.type helper program) In some cases useful info is found in syslog - try dmesg | tail or so If I do mount -t 9p 192.168.18.180 /mnt, using the file server IP, I just get mount: permission denied But dmesg shows [88617.144804] p9_errstr2errno: server reported unknown error cannot attach as none before authentication, ONLY when I use the IP address--nothing appears when I use the /etc/hosts alias glenda. What am I missing? I have very little experience working with the in-kernel support for 9P. Somehow 9P and being a superuser feel mutually exclusive to me. Thus, I can only recommend 9pfuse. It worked quite well for the limited application I needed it for. Thanks, Roman.
[9fans] Different representations of the same file/resource in a synthetic FS
Working on a RESTful API lately (which is as close to working on a 9P filesystem as I can get these days) I've been puzzling over this issue: is content negotiation a good thing or a bad thing? Or to justify posting to this list: what would be the proper 9P way of not only representing different renditions of the same information in a synthetic filesystem but also give consumer a chance to declare *a set* of preferred ones. Lets assume a classical example (modified slightly to fit 9P): a synthetic filesystem that serves images from a web cam. The very same frame can be asked for in different formats (.gif, .png, .pdf, etc.). Is serving /date/time/camera-id/gif/frame /date/time/camera-id/png/frame ... /date/time/camera-id/pdf/frame and relying on reading /date/time/camera-id for the list of supported representations really better than what HTTP content negotiation offers? Thanks, Roman.
Re: [9fans] Configuring NFS
On Tue, 2009-06-02 at 10:30 -0700, John Floren wrote: Has anyone here successfully set up nfsserver to share Plan 9 files with Unix machines? The examples given in the man pages are rather... opaque. All I want to do is share one directory tree (/lib/music, in particular) with a number of independent Linux laptops and workstations. I used it in combination with Solaris. I'm looking into NFS because it seems that it has about the lowest barrier to entry of all the possible file-sharing methods. Any other suggestions would be appreciated. Whether or not to use NFS depends greatly on what is on the other end. What kind of UNIX? Thanks, Roman.
Re: [9fans] Contrib index, snip
On Thu, 2009-04-23 at 17:07 -0400, Anthony Sorace wrote: Unrelated, about a month ago I put together snip, [3] a little pastebin-like service for sharing snippets of code (or whatever). Details on the snip's contrib page [4], but basic usage is snip /some/file to paste a snippet (/dev/snarf is a useful /some/file), which will return a path to the new snippet, or snip unadorned, which will list currently-available snippets. Reminds me of gist: http://gist.github.com/ http://www.sitepoint.com/blogs/2008/07/24/github-gist-is-pastie-on-steroids/ Thanks, Roman.
Re: [9fans] Git Mirror
On Thu, 2009-04-23 at 09:25 -0500, Eric Van Hensbergen wrote: I've started a public nightly mirror of (the source code bits) from sources using github: http://github.com/ericvh/plan-9/tree/master Great! What's your policy for updating the tree w.r.t. the actual sources? Thanks, Roman. P.S. Not that it changes all that often, but still...
Re: [9fans] 9p2010
On Thu, 2009-04-23 at 18:53 +0100, roger peppe wrote: i wonder how many things would break if plan 9 moved to a strictly name-based mapping for its mount table... What exactly do you mean by *strictly* ? Thanks, Roman.
Re: [9fans] web server
On Sun, 2009-04-19 at 00:13 +0200, Uriel wrote: My criticism was directed at how they are actually used in pretty much every web 'framework' under the sun: with some hideously messy ORM layer, they plug round Objects down the square db tables, and all of it to write applications which really are representing files (accessed over HTTP). I'd say that the biggest reason for DB overuse by Web folks is the fact that this is how they get persistence for their data while still being able to build distributed applications. In general, there are only two ways of having persistent data: * DBs * FSs (well, ok, there's third these days) FSs (under most OSes) have been way to clunky in the presence of any kind of distribution. Hence the DBs. So by using files to store and model data not only avoids having to map a fs-like interface to a table oriented one, but the object oriented convolution in between. And that is short is what allows you to write a blog engine in three lines of rc, because rc and the rest of the toolkit that comes with it are designed to work on and with files and file paths. FSs have a bit of a downside in how they make everything look like tree structures. This is not that big of a deal when you can have truly dynamic trees, but I still haven't seen how werc takes care of that. Thanks, Roman.
Re: [9fans] web server
On Sat, 2009-04-18 at 19:19 +0200, Enrico Weigelt wrote: yes. there are several web servers, including one in the standard dist. however, rails or merb might be something you'd have to do yourself. Did anyone already get java running on Plan9 ? Java is too many things. Strictly speaking, a sane implementation of JVM running natively on Plan9 could be a good thing. I'm not sure whether Sun's JVM would be a managable thing to port, but long time ago in another life I've seen a really good attempt at [re]implementing JVM by some guys from Finland. Not sure the project is still alive though. Thanks, Roman.
Re: [9fans] web server
On Fri, 2009-04-17 at 12:54 +0100, maht wrote: How difficult would it be to use rails or merb in plan9? Is it feasible? Not Rails or merb or anything non Plan 9 but a few of us are building an rc shell based system that works anywhere CGI and Plan 9 / plan9port is available. http://werc.cat-v.org/ I was not aware of werc. Is there a good doc for it? Thanks, Roman. P.S. So far it seems that werc wouldn't be able to manage highly dynamic and volatile URI hierarchies as long as it is run under anything but Plan9. Ironically it doesn't seem to run there.
Re: [9fans] J9P/StyxLib
On Wed, 2009-04-01 at 22:02 +0200, Bernd R. Fix wrote: As I wrote in an earlier mail, I am not too deep into this licensing stuff, but I know what I would like to have for my software: I want it Open-Source - that's my basic 'statement'. For me this means: I am willing to share my ideas (and code for that matter) with people interested in it. Im am even willing to give all people the right to base their own work on it and/or to modify it to their own liking. All I am asking for is that these people share their ideas and code just like I did - at least if they distribute their work. Essentially, that's it. Maybe I am wrong, but I had the impression that the GPL serves this purpose best - from my point of view at least. I understand that there are two cases which lead to problems with a GPL project, but I believe both cases can be solved: 1.) You want to use it in an commercial project and can't/don't want to share your ideas and code. Assuming you are not a criminal, you can't include the software or derived work into your product - the GPL permits that. But you can still license a commercial use with the copyright holder(s) in such cases. If you don't share ideas, at least share your money. 2.) You have an OS project with a different, incompatible license and want to include a GPL project or base some work on it. I am sure that this problem occurred many times in the past; maybe there even exists a 'best practice' approach how to deal with this. To be honest: I don't think that the first case is an argument against the GPL - not for me. I am more worried about the second case. So my question to you licensing experts: is there a better license that follows my basic statement (see above) and allows better integration into other OS licenses? If I have a better license model, I am certainly willing to change to it. There's a choice of licenses available that fit a pretty wide range of goals than an individual might have. Now, my personal experience have taught me that you have to always look at the price you pay for your beliefs. For me it boils down to (in the order of relationship): * GPL severely reduces the applicability of the code that I'm producing. One major consequence of that is my code is not taken places. The sheer pleasure of seeing your name on the About/License dialog of the iPhone/Windows (and BSD makes them do that if they use your code) is much more important to me than the closed sourced nature of the device or an application that uses my code. * Volume drives value. If your code is taken places somehow the stream of ideas, offers, etc. follows. In fact, I'd say if your code is *not* widespread because of the licensing issues, you have less of a chance to collaborate on it with somebody. * Which bring us to the final point -- if you stuff is good idea folks who want it are likely to re-implement it no matter what. They'd rather not waste their time and take it from you, but if your licensing doesn't allow them to -- they will. At that point you are no longer the host of the party you are standing in line withe everybody else to be let in. Case in point: ZFS on Linux. These three things tilt me strongly in favor of BSD. Your mileage may vary, of course. Oh, and here's one final point: it seems to me that (at least!) LGPL would be as good for your intended purposes as GPL is, without the nasty side-effects. Thanks, Roman. P.S. Arguably, the lets share things and figure out how to profit later model could be blamed for Sun's performance as of late. I'm not a businessman I wouldn't know. What I know though, is that it makes me stick with the company and refuse Google interviews and things like that. Somehow it just feels good. I don't know any other place where the same level of transparency and openness would be possible (if you do -- let me know ;-)).
Re: [9fans] J9P/StyxLib
This is seriously cool and must be added to: http://9p.cat-v.org/implementations Thanks, Roman. On Wed, 2009-04-01 at 13:43 +0200, Bernd R. Fix wrote: Hi, I just want to announce that a new 9P-related framework has been published (pre-alpha status, PoC). You find the current project documentation on the project homepage http://aspector.com/~brf/J9P;; the published packages are available on SourceForge: https://sourceforge.net/projects/j9pstyxlib/;. J9P is a pure Java implementation of the 9P(2000) protocol including authentication and message digests/encryption. It comes with a generic 9P server that publishes namespaces that are assembled from Java objects. File operations in the namespace are mapped to Java method calls; the called object handles the operation accordingly. This way it is quite easy to integrate non-9P services (like SQL databases) into 9P networks. Have fun, Bernd.
Re: [9fans] J9P/StyxLib
On Wed, 2009-04-01 at 18:49 +0200, Bernd R. Fix wrote: David Leimbach schrieb: Anyway to get a non GPL v3 licensed version from you? I may not be able to use this implementation for what I want otherwise. I was actually planning on doing this myself, anyway at one point, and BSDLng it. I guess there is a clash of licenses between your project and J9P. So what licence are you using (I assume it is no commercial project) and what makes it problematic? I am not too deep into this licensing business. As (currently) sole copyright holder I can make exceptions, but I feel that this problem should be solved in a more general way. Any ideas? Feel free to contact me via private mail on this. I thought about using the LGPL for the project and might reconsider that once a stable stage is reached. Not implying anything, just a question: what made you pick GPL in the first place? Thanks, Roman. P.S. Personally, I try to license my stuff under as non-restrictive license as possible (BSD or at least LGPL) that still protects me. That said, I do understand people who use GPL as a statement, not because the license is particularly good.
Re: [9fans] plan9 for calculations
On 03/27/09 14:31, Rudolf Sykora wrote: Hello everybody, I noticed there are some thoughts about using plan9 on supercomputers. For me supercomputers are usually used to do some heavy calculations. And this leads me to a question. What software is then used for programming these calculations? (I mean e.g. linear algebra, i.e. matrix, calculations.) Where can one read about that? If you are talking about established practices then supercomputing *almost* always means Infiniband+MPI (managed by a grid engine). On fat nodes (the kind of machines Sun used to sell) you might also find OpenMP. But there will always be MPI, since doesn't mean how fat the node is -- the cluster is fatter. On the language side I've seen predominantly Fortran and C++, although Ron was telling me horror stories about Python and some other goo. As far as the libraries go: linpack is almost always there, but the good place to take a look at what's relevant is here: http://docs.sun.com/app/docs/doc/819-0497 PS.: It could be that plan9, being more a os-research system than anything else, is simply no suitable for such a use (there are no plotting libraries, other utilities). Perhaps it's not a good idea at all to try to use plan9 like that because it would be more work than anything. Maybe using linux for such things with all its tools is just ok. If you share this idea, just say it too, please. My personal take is that Plan9's forte might be the sane clustering of things. MPI and grid engines is really quite horrible, but it is pervasive. Thanks, Roman.
Re: [9fans] request for more GSoC project suggestions
On 03/25/09 02:12 PM, Charles Forsyth wrote: A modern cfront is nearly impossible. Templates make it hella-hard. really? how is that? Everything is possible. It is software, after all. But it is not practical. The original cfront was, to some extent, a cpp(1) on steroids. AFAIR, it operated by manipulating C source code. With modern C++ things like inlines, templates and concepts operate at a level of AST. I guess one could use C for an AST representation, but that would be a pretty daring feat. Thanks, Roman.
Re: [9fans] THnX status?
On 03/16/09 06:01 PM, ron minnich wrote: skip lguest. What I'm looking at now is tinycore linux: tinycorelinux.org and vx32. Much easier. Makes a nice terminal. I have to add some things to it, it doesn't come w/wireless. That is all fine for the terminal (I suppose you really mean running tinycorelinux.com on bare metal and running 9vx on top of it) but shouldn't there also be a [para]virtualization solution for Plan9? You say 'skip lguest' -- that's fine. But what's the best alternative for running Plan9 server on the same bare metal that needs to run something else? Thanks, Roman.
Re: [9fans] threads vs forks
Clojure is definitely something that I would like to play with extensively. Looks very promising from the outset, so the only question that I have is how does it feel when used for substantial things. Thanks, Roman. P.S. My belief in it was actually reaffirmed by a raving endorsement it got from an old LISP community. Those guys are a bit like 9fans, if you know what I mean ;-) On Tue, 2009-03-03 at 10:38 -0800, Bakul Shah wrote: On Tue, 03 Mar 2009 10:11:10 PST Roman V. Shaposhnik r...@sun.com wrote: On Tue, 2009-03-03 at 07:19 -0800, David Leimbach wrote: My knowledge on this subject is about 8 or 9 years old, so check with your local Python guru The last I'd heard about Python's threading is that it was cooperative only, and that you couldn't get real parallelism out of it. It serves as a means to organize your program in a concurrent manner. In other words no two threads run at the same time in Python, even if you're on a multi-core system, due to something they call a Global Interpreter Lock. I believe GIL is as present in Python nowadays as ever. On a related note: does anybody know any sane interpreted languages with a decent threading model to go along? Stackless python is the only thing that I'm familiar with in that department. Depend on what you mean by sane interpreted language with a decent threading model and what you want to do with it but check out www.clojure.org. Then there is Erlang. Its wikipedia entry has this to say: Although Erlang was designed to fill a niche and has remained an obscure language for most of its existence, it is experiencing a rapid increase in popularity due to increased demand for concurrent services, inferior models of concurrency in most mainstream programming languages, and its substantial libraries and documentation.[7][8] Well-known applications include Amazon SimpleDB,[9] Yahoo! Delicious,[10] and the Facebook Chat system.[11]
Re: [9fans] threads vs forks
On Tue, 2009-03-03 at 23:24 -0600, blstu...@bellsouth.net wrote: it's interesting that parallel wasn't cool when chips were getting noticably faster rapidly. perhaps the focus on parallelization is a sign there aren't any other ideas. Gotta do something will all the extra transistors. After all, Moore's law hasn't been repealed. And pipelines and traditional caches are pretty good examples of dimishing returns. So multiple cores seems a pretty straightforward approach. Our running joke circa '05 was that the industry was suffering from the transistor overproduction crisis. One only needs to look at other overproduction crisis (especially the food industry) to appreciate the similarities. Now there is another use that would at least be intellectually interesting and possible useful in practice. Use the transistors for a really big memory running at cache speed. But instead of it being a hardware cache, manage it explicitly. In effect, we have a very high speed main memory, and the traditional main memory is backing store. It'd give a use for all those paging algorithms that aren't particularly justified at the main memory-disk boundary any more. And you can fit a lot of Plan 9 executable images in a 64MB on-chip memory space. Obviously, it wouldn't be a good fit for severely memory-hungry apps, and it might be a dead end overall, but it'd at least be something different... One could argue that transactional memory model is supposed to be exactly that. Thanks, Roman.
Re: [9fans] threads vs forks
On Tue, 2009-03-03 at 07:19 -0800, David Leimbach wrote: My knowledge on this subject is about 8 or 9 years old, so check with your local Python guru The last I'd heard about Python's threading is that it was cooperative only, and that you couldn't get real parallelism out of it. It serves as a means to organize your program in a concurrent manner. In other words no two threads run at the same time in Python, even if you're on a multi-core system, due to something they call a Global Interpreter Lock. I believe GIL is as present in Python nowadays as ever. On a related note: does anybody know any sane interpreted languages with a decent threading model to go along? Stackless python is the only thing that I'm familiar with in that department. Thanks, Roman.
Re: [9fans] Calling vac from C
On Tue, 2009-02-24 at 10:54 -0500, erik quanstrom wrote: about 5 years ago i took a class on performance tuning Solaris. The instructor claimed that fork was expensive because accounting is never really turned off, just piped to /dev/null. there is no accounting overhead for threads. I never bothered to verify this, but now that this comes up, I'd tempted. there's no need to guess. here's the source code. http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/fork.c cfork is ~525 lines long and seems to take the curious tack of forking all the lwps associated with a process. that would be forkall(), not fork1()/fork() Thanks, Roman.
Re: [9fans] Calling vac from C
On Tue, 2009-02-24 at 11:22 -0500, erik quanstrom wrote: cfork is ~525 lines long and seems to take the curious tack of forking all the lwps associated with a process. that would be forkall(), not fork1()/fork() my mistake. i assumed that since isfork1 was a flag, that it was not the normal path through the code. silly me. so where's the mythical accounting? It could have been the old accounting. Solaris 10 changed a lot of that and made things like microstate accounting on by default, thus, possibly eliminating the kind of bottlenecks the instructor was referring to. More on that here: http://blogs.sun.com/eschrock/entry/microstate_accounting_in_solaris_10 Thanks, Roman.
Re: [9fans] Venti by another name
On Wed, 2009-02-25 at 01:26 +0100, Enrico Weigelt wrote: But I really can't tell anything about the space saving. (one of the primary decision for venti is that it will be clustered some day ... ;-o) Clustered? Thanks, Roman.
Re: [9fans] source browsing via http is back
On Thu, 2009-02-12 at 07:49 -0500, erik quanstrom wrote: exactly. the point i was trying to make, and evidently was being too coy about, is that 330 odd gb wouldn't be as useful a number as the sum of the sizes of all the new/changed files from all the dump days. this would be a useful comparison because this would give a measure of how much space is saved with venti over the straightforward algorithm of copying the changed blocks, as ken's fileserver does. I'm confused. Since when did kenfs entered this conversation? I thought we were talking about how sources are managed today and how replica might make you waste some bandwidth (albeit, not all that much given how infrequently sources themselves change). Thanks, Roman.
Re: [9fans] Plan 9 source history (was: Re: source browsing via http is back)
On Wed, 2009-02-11 at 13:19 -0500, Venkatesh Srinivas wrote: On Wed, Feb 11, 2009 at 07:07:48PM +0100, Uriel wrote: Oh, glad that somebody found my partial git port useful, I might give it another push some time. Having a git/hg repo of the plan9 history is something I have been thinking about for a while, really cool that you got something going already. Will you provide a standard git web interface (and a 'native' git interface for more efficient cloning)? We'll have a git web interface up pretty soon, within this week. Since its a more or less r/o Git repo, why not also provide a mirror on one of these guys: http://github.com/ http://repo.or.cz/ http://gitorious.org/ Not only would it reduce the stress on your servers, but it'll also enable some of the source-browsing features that these sites implement. I can set things up myself, as long as you give me *some* kind of access to your Git repo. Thanks, Roman.
Re: [9fans] Plan 9 source history (was: Re: source browsing via http is back)
On Tue, 2009-02-10 at 20:43 -0500, Nathaniel W Filardo wrote: Incidentally, a git repository of the crawls, from 2002/1212 to 2009/0205, is available at http://mirrors.acm.jhu.edu/trees/plan9native/ . Git gets the data down to 165M after a gc run, so perhaps it's a better idea than a venti-based mirror. Where did 165M came from? The history itself seems to be only about 58M or so: $ wget http://mirrors.acm.jhu.edu/trees/plan9native/.git/objects/pack/pack-afe021812ab52f698895941f8eb5ad4e3d75020e.pack $ ls -l pack-afe021812ab52f698895941f8eb5ad4e3d75020e.pack -rw-rw-r-- 1 rs76089 staff61039150 Feb 11 06:40 pack-afe021812ab52f698895941f8eb5ad4e3d75020e.pack And, after the following simple minded manipulations: $ git init $ git unpack-objects pack* $ git checkout -b master 68e58814202bccfbd7186962daedd754ae76d7df warning: You appear to be on a branch yet to be born. warning: Forcing checkout of 68e58814202bccfbd7186962daedd754ae76d7df. Checking out files: 100% (14229/14229), done. Already on master $ git repack -ad --window 100 --depth 100 Counting objects: 39971, done. Compressing objects: 100% (39354/39354), done. Writing objects: 100% (39971/39971), done. Total 39971 (delta 25278), reused 0 (delta 0) Made it even smaller (you can fine tune it even more, based on usage requirements): $ ls -l .git/objects/pack/*.pack -r--r--r-- 1 rs76089 staff57694396 Feb 11 11:03 .git/objects/pack/pack-afe021812ab52f698895941f8eb5ad4e3d75020e.pack I haven't managed to make my version of Uriel's port (thanks for the start! :) ) of git do the right thing in enough cases yet, so the git repo may not be updated for a while, but I figured somebody might want to play with it in the interim. The coolest things, of course, would be to have a way of running git on the bell labs end. But doing a replica and repacking everything locally is not bad at all. Thanks, Roman.
Re: [9fans] source browsing via http is back
On Tue, 2009-02-10 at 16:32 -0500, erik quanstrom wrote: I again propose that sources should be mirrorable via venti (and venti/copy -f); the nightly snapshots would be walked with auth/none vac into a publically readable venti (venti/ro proxy) and the scores published (and signed). In order to make this more palatable, it may be worth developing a venti proxy that attempts to pull blocks from closer ventis rather than further ones and to make sources' public venti artificially further away (induce a delay of half a second or something per Tread). I've some tentative writeup on https://wiki.ietfng.org/pub/Plan9/VentiMirror and even some code flying locally but nothing about which to be proud. i'm still not following why replica won't work? getting in underneath the fs seems to require some extra justification and it seems to require some very low-level modifications. and yet the file interface provides what i think one would need for such a project. what is wrong with replica that can't be reasonably fixed? since replica requires some (albeit automatic) periodic work on the server end it means that there's one more thing for bell lab folks to care about and maintain. that said, a brand new Venti proxy or what not will probably be even worse for them :-( Thanks, Roman.
Re: [9fans] FileServer grid
On Tue, 2009-02-10 at 09:06 +0100, Giacomo Tesio wrote: So far it seems that there are no ready-made 9P-based solutions available for what you have in mind. At least I don't know of any. In any solution available there are costs to pay (economical or temporary ones). On the side of existing tools/solutions you may find this one interesting: http://www.ultramonkey.org/ Thanks, Roman.
Re: [9fans] source browsing via http is back
On Tue, 2009-02-10 at 16:55 -0500, erik quanstrom wrote: i'm still not following why replica won't work? getting in underneath the fs seems to require some extra justification and it seems to require some very low-level modifications. and yet the file interface provides what i think one would need for such a project. what is wrong with replica that can't be reasonably fixed? since replica requires some (albeit automatic) periodic work on the server end it means that there's one more thing for bell lab folks to care about and maintain. that said, a brand new Venti proxy or what not will probably be even worse for them :-( the replica logs are already generated and already required for existing functionality — pull — to work. What do you mean they are already generated? The script(s) try to generate them. When they fail they need a manual intervention. That was my entire point. Thanks, Roman.
Re: [9fans] source browsing via http is back
On Tue, 2009-02-10 at 17:13 -0500, Nathaniel W Filardo wrote: On Tue, Feb 10, 2009 at 01:51:47PM -0800, Roman V. Shaposhnik wrote: since replica requires some (albeit automatic) periodic work on the server end it means that there's one more thing for bell lab folks to care about and maintain. that said, a brand new Venti proxy or what not will probably be even worse for them :-( Under the proposed scheme, clients and maybe mirrors, not sources, run the new proxy. Sources runs only a venti and venti/ro, unmodified, to allow clients and mirrors to fetch blocks, and auth/none vac. Is this unreasonable? It would be completely reasonable (and I wager *less* work for bell labs folks than keeping an eye on replica) if that venti was only hosting blocks coming from sources. As far as I know that's not the case. Thanks, Roman.
Re: [9fans] source browsing via http is back
On Tue, 2009-02-10 at 17:10 -0500, erik quanstrom wrote: On Tue, Feb 10, 2009 at 04:32:18PM -0500, erik quanstrom wrote: i'm still not following why replica won't work? getting in underneath the fs seems to require some extra justification and it seems to require some very low-level modifications. and yet the file interface provides what i think one would need for such a project. what is wrong with replica that can't be reasonably fixed? I wish to enable mirrors of sourcesdump as well. Replica would do lots of extra work and transfer, vs. venti/copy -f, yes? what extra work would that be, and if there is extra work, could you explain why this would be a problem? Correct me if I'm wrong, but my understanding of how pull works is that it pulls files in their entirety (IOW: cp /n/sources/... /) which means that shared blocks get copied as many times as there are files sharing them. Thanks, Roman.
Re: [9fans] FileServer grid
On Fri, 2009-02-06 at 23:26 +0100, Giacomo Tesio wrote: Hello every one... In a context of really heavy load and high availability needs, I'm evaluating plan 9 to implement a fileserver grid to be used by a web server for temporary storage (session's serializations, for example). What OS do you web servers run under? I'd like to build a Plan 9 grid exposing a unique filesystem mounted by all the web servers. Are you going to talk to this filesystem using 9P or something else? Each session could be accessible from any web server instantly, but what if a fileserver in the grid break? Is there a way to mantain such a session (actually the file storing the session data) available by keeping it sincronized beetween the Plan 9 fileservers? This is unclear. Please restate. Thanks, Roman.
Re: [9fans] Some arithmetic [was: Re: Sources Gone?]
On Thu, 2009-02-05 at 12:41 -0500, erik quanstrom wrote: http://www.google.com/search?q=09+f9; is that a legal url? I don't think it is a legal URL, but most browsers will turn it into a legal one before issuing a GET request. Thanks, Roman. P.S. Or am I missing some kind of a joke here? ;-)
Re: [9fans] Some arithmetic [was: Re: Sources Gone?]
On Thu, 2009-02-05 at 10:22 -0800, Micah Stetson wrote: http://www.google.com/search?q=09+f9; is that a legal url? P.S. Or am I missing some kind of a joke here? ;-) Intentional or not, it's a very good joke. but...but...erik always adds that look-i-am-using-plan9-smiley to all of his jokes. i'm so confused... Thanks, Roman.
Re: [9fans] Sources Gone?
On Tue, 2009-02-03 at 19:27 +0200, lu...@proxima.alt.za wrote: But I do not recall the details and I think Roman is the one who needs to recap this discussion and bring it to a conclusion. Wow! This ended up being quite a thread ;-) I'll try to comment on a couple of things first, in this single email, and then try to recap: erik if you want users, groups and access control, isn't the fs the erik place to go? i'm trying to see how doing fsey things at the erik venti level would be useful, but i don't see it yet. Yes, as I pointed in my prior reply to you the access control sure does belong to the FS. But... roger the attraction, for me at any rate, is that certain operations roger are really cheap and easy in venti, but expensive in the fs. roger cloning/copying a multi-gigabyte tree being the canonical roger example. ...if you completely firewall venti by the fossil, you can longer get the benefits roger is talking about (and these benefits is precisely what I'm after). Essentially, replica of a venti-backed fossils is only needed because there's no way to get to venti. All you see is an FS interface. Now, this conversation made me realize that since there has to be a proxy anyway (just as Anthony, I'm not fully convinced by roger's proposal) and since most of what this proxy needs to care about is FSish type of things may be the answer is extending fossil, not venti. IOW, augmenting fossil with a set of API that would let two ventis exchange filesystem blocks, but only as long as the user is authorized to do so. This takes care of Erik's remark that venti doesn't know what's in the blocks. Sure it doesn't. But now fossil (as a proxy) does. Thanks, Roman.
Re: [9fans] Sources Gone?
On Tue, 2009-02-03 at 17:30 +, Brian L. Stuart wrote: information can't leak in principle, but root scores are dangerous, which is why open-access venti servers are problematic - if such a score *does* happen to leak, then unconditional access to all your data has also leaked. If I understand correctly, this line of discussion is primarily motivated by the idea of an open-access venti server. Correct. But with this caveat: I only care about the blocks that are part of vac structures. Erik keeps reminding us that venti doesn't care about what's in the blocks. True. But now, I've drawn a line. There's only one type of blocks that I'm interested in -- blocks which are part of vac structures. The venti itself doesn't need to be open- access if there's a proxy server that is. Absolutely! Maybe I'm misunderstanding the problem we're trying to solve, but if the objective is to provide open venti access but the necessary protection mechanisms really belong elsewhere, it seems reasonable to create the elsewhere and not incorporate them into venti. Looks like we're in a complete agreement. And thanks for the summary! Thanks, Roman.
Re: [9fans] Pegasus 2.6 is released
On Mon, 2009-02-02 at 13:22 -0800, John Barham wrote: You're missing the beauty of 9p. Who needs dynload() when you have mount()? Mount allows me to add new names to the process namespace. Dynload allows me to call functions or access data in a library that is not known to the process (e.g., scripting language interpreter) until runtime. They solve different problems. Depends on your point of view. Except for accessing data directly in the same address space, dynload() is just a way of doing fast RPC. In that line of thought, 9P offers you a very similar mechanism. I think the most obvious example of how 9P can be used to provide the kind of extensibility that folks usually associate with dynload() is factotum. Especially if you compare it with things like PAM. Thanks, Roman.
Re: [9fans] Pegasus 2.6 is released
On Mon, 2009-02-02 at 13:32 -0800, David Leimbach wrote: I mean sure you could use FTP to transfer files, but the old shell based tools are automagically plugged in with network capabilities when they deal with a FTP backed namespace right? So without any binary loader capabilities cp mv and other existing small programs are now plugged in. Right. That plus the fact that the plugin is now generally available over the network makes it much more interesting. In fact, these current trend towards REST in web services seems to be a validation of 9P view of the world. Thanks, Roman.
Re: [9fans] Pegasus 2.6 is released
On Mon, 2009-02-02 at 14:12 -0800, ron minnich wrote: On Mon, Feb 2, 2009 at 1:32 PM, David Leimbach leim...@gmail.com wrote: They solve the same class of problems, if you step back far enough. If your application's mechanism of dealing with processing is to use the namespace, then binding new functionality over old is roughly equivalent to a plugin mechanism. I hate to be the one to bring this up but ... if you are providing some extended (e.g.) math functionality to a program with a shared library, people are going to be upset with you if you argue that it can be done with RPC. I hope the reason is obvious :-) It is. It is a trivial case, after all. In non-trivial ones, the same kind of discussion used to be quite popular in OpenMP vs. MPI circles. And I shouldn't be the one to tell you where it is going, right? Thanks, Roman.
Re: [9fans] Pegasus 2.6 is released
On Mon, 2009-02-02 at 23:22 +0100, Francisco J Ballesteros wrote: But can't you `script' by calling an external program, sending it your input, and reading its output? Well, the way I see it: exec'ing is just a way to get to a transient channel. Its no different from that very same channel being present permanently in /srv or /mnt/factotum/rpc. There's *slightly* less overhead with pipes, but that's about it. Thanks, Roman.
Re: [9fans] Sources Gone?
On Fri, 2009-01-30 at 07:18 +0200, lu...@proxima.alt.za wrote: Some level of smartness in how block traversal is made needs to be there. That involves partitioning, which defeats the fundamental mechanics of venti. I don't think it does. At least not in a way that is obvious to me. The one and only fundamental limitation of the current interface offered by venti is that I can give it a score to something that doesn't belong to me and it gives me the information back. It is the limitation of the API, not the way data is managed. IOW, if a block that I genuinely own happens to also be referenced from a hierarchy that I do NOT have access to -- its ok. It then becomes preferable to run distinct venti services, which is the only way in which different backing stores can be used at this stage. Hm. I guess I need to understand what is the problem you seem to be worried about. Thanks, Roman.
Re: [9fans] 9vx as a cpu server?
On Sun, 2009-02-01 at 20:27 -0800, Russ Cox wrote: as for listening, 9vx by default uses the host ip stack, and plan 9 services tend to use their own port numbers, And sometimes these port # tend to be 1024 which means that you have to run 9vx as root. Thanks, Roman.
Re: [9fans] Sources Gone?
On Mon, 2009-02-02 at 17:43 -0500, erik quanstrom wrote: I don't think it does. At least not in a way that is obvious to me. The one and only fundamental limitation of the current interface offered by venti is that I can give it a score to something that doesn't belong to me and it gives me the information back. It is the limitation of the API, not the way data is managed. IOW, if a block that I genuinely own happens to also be referenced from a hierarchy that I do NOT have access to -- its ok. ownership doesn't mean anything at the venti level. it really is just a virtual disk drive with lba80 content addressing. one doesn't own blocks on a regular disk drive, either. Depends on how you look at it. From the drive's perspective -- you're right. Nobody owns blocks. However, if a certain block happens to be part of a filesystems that uses this particular drive then the ownership can and will be tracked. suspending the preceeding logic for a bit, supposing that you did track ownership, then No need to suspend the logic and run this thought experiment. I have no interest in assigning ACL to blocks. That's why I said that the API that venti currently has is ill-suited for the kind of public usage I have in mind. That doesn't mean that it should be replaced or mutilated. It simply means firewalling in a spirit of venti/ro The proxy API will have to track the ownership. And it is very likely to be more hierarchy-oriented, than stand-alone blocks-oriented. Thanks, Roman.
Re: [9fans] Sources Gone?
On Thu, 2009-01-29 at 13:12 +0100, Uriel wrote: The issues with replica go beyond its tendency to wipe out complete file systems. It includes, among other things, the performance of a drunken slug, and as you well point out, the skils of a schizophrenic monkey for managing local changes. Full disclosure: I don't use replica. But... All this has been solved by git and hg; and git and hg would *never* wipe out your local files simply because the backing store for the repository you are pulling from happens to break, the pull simply would fail and leave your local repo intact, and when the remote repo is brought back, all would work just fine. ...I'm really somewhat of a Git buff. So I'm obviously interested in this discussion. As was pointed out in a different thread Git architecture is, in fact, quite close to venti/fossil. Venti is the immutable hash addressed history and fossil is the index. Thus the way Git transfers history between the repositories is conceptually very similar to transferring venti blocks that can be reached from a designated set of VtRoots. This has a number of useful properties in Git: the state of the history repository has nothing to do with the state of your local write buffer (index). You may fetch quite a few additional blocks of history, but that doesn't force you to reformat your write buffer. In fact, it is usually a good idea to: fetch, inspect and only then do a merge. replica, on the other hand, tries to not rely on anything but its own functionality, effectively making it possible to manage changes backed by something other than fossil/venti. Replica is trying to be more like rsync, than Git. I've come to realize that this might be, in fact, the key problem. Git itself is not afraid to admit that it *is* a filesystem. Linus said it explicitly on quite a few occasions. We already have a filesystem. Do we need another one? Oh, and they are both *excellent* at helping one keep track of local changes without messing everything up. Of course they also help with things like merges, changelog generation, etc. but I suspect those things are not really wanted. And that is a complementary problem to all of the above: your history is as good (and as helpful in doing merges, etc.) as is the effort put into creating it in the first place. A conversation on this list a month or so ago completely convinced me that those who make changes to Plan9 sources see very little value in maintaining history that way. Thanks, Roman.
Re: [9fans] Sources Gone?
On Thu, 2009-01-29 at 08:15 -0800, ron minnich wrote: On Thu, Jan 29, 2009 at 4:12 AM, Uriel urie...@gmail.com wrote: All this has been solved by git and hg; and git and hg would *never* wipe out your local files simply because the backing store for the repository you are pulling from happens to break, Have you used git much? I do ;-) Sure, it's nice. Have you tried it when it hits 6 gbyte size as we have here, and repo is filled with binaries, not just source? We hit exactly those very problems when trying to evaluate Git for a huge internal project with a history going back to '89. We found very attractive solutions in Git (but not in Mercurial or Bazaar at that time) for all the issues you've identified. YMMV, of course, but I can share more of my experience off the list, since the subject has absolutely nothing to do with Plan9. Thanks, Roman. P.S. In all fairness, the evaluation happened about a year ago. I hear that Mercurial has improved since then. It is also possible that Git deteriorated, although I doubt it.
Re: [9fans] Small program PlanKey (paraphrase of DOSKey)
On Thu, 2009-01-29 at 08:53 -0500, erik quanstrom wrote: How about turning acme to universal UI, in the style of old Oberon? Acme very deeply believes that everything's just text. It would be substantial effort to get it to be any more universal than that. I'm aware of at least two independent efforts by very smart people who stalled at about the same place. i was hoping to avoid this discussion and keep things simple. the problem with adding graphics to acme is kind of interesting though. text pretty much does it's own layout. You've hit the nail on the head with this comment. It seems that almost all layout systems spend 99% of their smarts laying out blocks of graphic information *and* trying to figure out how to make text be still self-layingout. And I do mean all: from TeX, lout, all the way to HTML/CSS. If we were to learn from their experience I'd say it is a heck of a job to get it all right and still maintain your sanity. Thanks, Roman.
Re: [9fans] Sources Gone?
On Thu, 2009-01-29 at 08:37 -0500, erik quanstrom wrote: and as you well point out, the skils of a schizophrenic monkey for managing local changes. well then, please show me how hg/git or whatever would save me from the situation outlined. how would hg/git know that i was really using some code which i had never locally modified and was then removed on sources? it wouldn't. but the fact that it encourages a three step process: 1. get the immutable history (whatever it is) but don't modify your write buffer 2. inspect history. Git offers quite a few nice tools to manage your local changes in the interim, but it is conceptually similar to formatting an extra fossil buffer with a score corresponding to the tip of the history and simply comparing it to what you have. 3. only when you are absolutely certain, you combine your local changes with whatever history brought you, then you commit and get the new score makes it far less dangerous. With replica (on those two or three occasions that I used it) it seemed that your only option is to hope for the best. It doesn't manage history. It manages your write buffer. Thanks, Roman.
Re: [9fans] Sources Gone?
On Thu, 2009-01-29 at 09:18 -0800, Russ Cox wrote: Onr fundamental difference is that the latter set is intended to keep trees exactly in sync, trees tend to be highly overloaded, but if you refer to the filesystem hierarchy as seem by open, then the above statement, if applied to Git, is misleading. Git specifically opted out for some additional complexity in favor of treating the non-mutable hash addressed history and write buffer differently. Not realizing that git makes this distinction, makes people surprised when they try to push their own history into the repositories of others only to find out that the tree they see locally doesn't match the tree that is on the other end. This rigid distinction was one of the factors that swayed us in favor of Git when we did internal evaluation of DSCMs about a yer ago. It really makes things much more manageable. The replica tools are not SHA1-based because they cannot depend on the user having a venti to manage the blocks, and managing a separate copy of the data (like the dvcs's do) seemed out of character with fitting well into the surrounding system. That is well understood and replica definitely has its place in Plan9. That said, what would be your thoughts on developing the tools (and interfaces perhaps) for fetching up venti blocks between two systems in a secure and manageable way. It seems that as a *complimentary* solution this would achieve quite a few benefits of Git/etc. Thanks, Roman.
Re: [9fans] Sources Gone?
On Thu, 2009-01-29 at 14:33 -0800, Russ Cox wrote: On Thu, Jan 29, 2009 at 1:09 PM, Roman V. Shaposhnik r...@sun.com wrote: I don't know how well Git handles this; I apologize for that. Git doesn't get annoyed. In fact, with things like git stash you can even test incremental changes to the merge without loosing the state of your actual filesystem tree. I think using venti as a backend for Git would buy you very little. Git already does a good job of managing its blocks. Perhaps, I haven't made myself clear. What I asked you about had nothing to do with Git. I was suggesting that letting two venti systems efficiently trade blocks would be a desirable addition to the system. There was a question on this list not long time ago whether getting access to venti blocks of the sources would be possible. The answer at the time was no. This is understandable since the stock venti doesn't really offer any kind of security mechanism for doing that. However, the very fact that somebody else asked that question suggests that the feature is not useless one. Thanks, Roman.
Re: [9fans] Sources Gone?
On Thu, 2009-01-29 at 16:42 -0500, erik quanstrom wrote: That said, what would be your thoughts on developing the tools (and interfaces perhaps) for fetching up venti blocks between two systems in a secure and manageable way. i think this harks back to ye olde dump. the main difference is that inode number has now become a score and gotten much fatter. the problem at this level is it's hard to maintain any differences. (you can't skip one of a sequence of 6 incremental dumps.) To use git as an example here, it has a concept of a shallow clone, where it lets you skip the history older than a particular date. or apply changes from one venti to another. What do you mean by apply changes? Each venti has a set of blocks corresponding to vac hierarchies. Each vac hierarchy has a single parent. Retrieving the missing blocks reachable from a hierarchy of interest to you is all that is needed. i don't see how to make sense of venti-level syncing unless it is so basic that you dump all the blocks from one venti into another. in which case, no special tools are needed. Some level of smartness in how block traversal is made needs to be there. I would also like to have an agent close to the actual server hosting venti archive being able to do things on my behalf and only sending the results back (e.g. traversing the hierarchies only to determine that certain things are not needed is painful over the network). Plus there has to be a security mechanism that would not allow me to request random blocks, unless I'm authorized. Thanks, Roman.
Re: [9fans] Small program PlanKey (paraphrase of DOSKey)
On Mon, 2009-01-26 at 22:35 -0800, Akshat Kumar wrote: 2009/1/26 Roman Shaposhnik r...@sun.com: ... Yeah, that's about the only thing that is useful to me as well. The rest requires too much mousing around and in general it is quicker for me to compose the command line anew rather than trying to edit the bygones. There are normally two cases in a rio rc window with excessive output and commands floating about: (1) you want to retrieve a prior command and know quite exactly what it is, or unique keywords to identify it, but simply don't have the patience, will-power, eyes, hands, whatever, to type it again or go looking for it; I often wished rio windows had Find Prev Find Next functionality so that at least I can navigate all that text that it holds simply with my mouse. Thanks, Roman.
Re: [9fans] Small program PlanKey (paraphrase of DOSKey)
On Tue, 2009-01-27 at 14:25 -0800, Christopher Nielsen wrote: ... I've seen this study and I tend to believe it. But there's a gotcha: the kind of work that I and other software engineers do with computers is almost orthogonal to what the study was focusing on. I don't believe anybody else, but engineers, spend the majority of time dealing with text. Who do you think Plan 9 was designed for and by? For researches by researches. You have a different explanation? Maybe you should try using the system without all your preconceived notions of what should and should not be. I'm using 9vx on a daily basis (and there used to be a certain level of 9term, but it had declined now). I've been using Plan9 in one form or the other since 2000. Do my notions still seem preconceived to you, or can we, please, move on? Thanks, Roman.
Re: [9fans] Small program PlanKey (paraphrase of DOSKey)
On Tue, 2009-01-27 at 14:43 -0800, Christopher Nielsen wrote: On Tue, Jan 27, 2009 at 14:31, Roman V. Shaposhnik r...@sun.com wrote: On Tue, 2009-01-27 at 14:25 -0800, Christopher Nielsen wrote: ... I've seen this study and I tend to believe it. But there's a gotcha: the kind of work that I and other software engineers do with computers is almost orthogonal to what the study was focusing on. I don't believe anybody else, but engineers, spend the majority of time dealing with text. Who do you think Plan 9 was designed for and by? For researches by researches. You have a different explanation? By programmers for programmers. Are you a programmer? Care to give pointers to the projects you've been on? No need to reply. This is my last post on the subject. I get it! You are not a programmer -- you are a phone prankster. Thanks, Roman.
Re: [9fans] Small program PlanKey (paraphrase of DOSKey)
On Tue, 2009-01-27 at 15:11 -0800, Christopher Nielsen wrote: On Tue, Jan 27, 2009 at 14:50, Roman V. Shaposhnik r...@sun.com wrote: Are you a programmer? Care to give pointers to the projects you've been on? I am not going to get into a pissing contest with you. Check the archives. But you did! You told me to check the archives ;-) And you lied too. How adorable. Now, if you have something constructive to say, please say it. If the only reason you came here is to get the kids off your lawn -- just beat it old man. Eris has more sense in what she posts here. Thanks, Roman. P.S. I apologize for the rest of list, but I just can't stand the ivory tower attitude. Even if I am unworthy of Plan9 wisdom, I would like that to be articulated, not spitted out. P.P.S. As for me -- this is my last email in this thread.
Re: [9fans] Changelogs Patches?
On Mon, 2009-01-26 at 08:53 -0500, erik quanstrom wrote: It depends on the vdev configuration. You can do simple mirroring or you can do RAID-Z (which is more or less RAID-5 done properly). raid5 done properly? could you back up this claim? Yes. See here for details: http://blogs.sun.com/bonwick/entry/raid_z does this depend on the amount of i/o one does on the data or does zfs scrub at a minimum rate anyway. if it does, that would be expensive. You can do resilvering (fixing the data that is known to be bad) or scrubbing (verifying and fixing *all* the data). You also can configure things so that bad blocks either trigger or don't automatic resilvering. Does this answer your question? no. not at all. Then, please, restate it. if you're serious about using ec2, one of the costs you need to control is your b/w usage. you're going to notice overly-aggressive scrubbing in your mothly bill. Only if you asked for that to happen. Its all under your control. You may decide to never ever do scrubbing. The scariest takeaway from the conference was: with the economy the way it is physical on-site datacenters are becoming a luxury for all but the most wealthy companies. Thus whether we like it or not virtual data centers are here to stay. if the numbers i came up with for coraid are correct, it would would cost coraid about 50x more to use ec2. that is, if we can run plan 9 at all. You may think what you want, but obviously quite a few existing small to mid-size companies disagree. Including a couple of labs with MPI apps now running on EC2. May be your numbers are wrong, may be your usage patterns are different. Who knows. Thanks, Roman.
Re: [9fans] Changelogs Patches?
On Mon, 2009-01-26 at 08:22 -0800, Russ Cox wrote: As for me, here's my wish list so far. It is all about fossil, since it looks like venti is quite fine (at least for my purposes) the way it is: 1. Block consistency. Yes I know the argument here is that you can always roll-back to the last known archival snapshot on venti. But the point is to kown *when* to roll back. And unless fossil warns you that a block has been corrupted you wouldn't know. I don't understand what you mean. Do you want fossil to tell you when your disk is silently corrupting data, or something else? Implementation vise I would be happy to see the same score checks that venti does implemented in fossil. Complaining like this: seterr(EStrange, lookuplump returned bad score %V not %V, u-score, score); Would be good enough. 2. live mounting of arbitrary scores corresponding to vac VtRoot's to arbitrary sub-directories in my fossil tree. After all, if I can do create of regular files and sub-directories via fossil's console why can't I create pointers to the existing venti file-hierarchies? The only reason this is hard is the choice of qids. You need to decide whether to reuse the qids in the archive or renumber them to avoid conflicts with existing qids. The vac format already has a way to offset the qids of whole subtrees, but then if you make the tree editable and new files are created, it gets complicated. I see. Thanks for the explanation. 3. Not sure whether this is a fossil requirement or not, but I feel uneasy that a root score is sort of unrecoverable from the pure venti archive. Its either that I know it or I don't. I don't understand what you mean here either. From a venti archive, you do cat file.vac to find the actual score. As I mentioned: this one is not really a hard requirement, but rather me thinking out loud. To me it feels that Venti is opaque. In a sense that if I don't know the score to give to flfmt -v then there's no way to browse through the venti to see what could be there (unless I get physical access to arenas, I guess). Now, suppose I have a fossil buffer that I constantly snap to venti. That will build quite a lengthy chain of VtRoots. Then my fossil buffer gets totally corrupted. I no longer know what was the score of the most recent snapshot. And I don't think I know of any way to find that out. The amazing thing to me about fossil is how indestructable it is when used with venti. I agree. That has been very much the case during my short evaluation of the two. It is actually quite remarkable how similar the models of fossil/venti and Git seem to be: both build on the notion of the immutable history. Both address the history by the hash index. Both have a mutable area whose only purpose is to stage data for the subsequent commit to the permanent history. Etc. I don't think it's too remarkable. Content hash addressing was in the air for the last decade or so and there were a lot of systems built using it. The one thing it does really well is eliminate any worry about cache coherency and versioning. That makes it very attractive for any system with large amounts of data or multiple machines. Once you've gone down that route, you have to come to grips with how to implement mutability in a fundamentally immutable system, and the obvious way is with a mutable write buffer staging writes out to the immutable storage. All true. Yet, it is surprising how many DSCMs that were built on the idea of hash addressable history got the implementation of mutability part wrong. Git is the closest one to, what I now understand, is the fossil/venti approach. Thanks, Roman.
Re: [9fans] Changelogs Patches?
On Tue, 2009-01-20 at 16:52 -0700, andrey mirtchovski wrote: for my personal $0.02 i will say that this argument seems to revolve around trying to bend fossil and venti to match the functionality of zfs and the design decisions of the team that wrote it. That is NOT the conversation I'm interested in. My main objective is to evaluate venti/fossil approach to storage and what kind of benefits it might provide. It is inevitable that I will contrast venti/fossil with ZFS, simply because it is the background I'm coming from. i, frankly, think that it should be the other way around; zfs should provide the equivalent of the fossil/venti snapshot/dump functionality to its users. that, to me would be a benefit. Ok. It is fair to turn the tables. So now, let me ask you: what are the benefits of fossil/venti that you want to see in ZFS? So far the only real issue that you've identified is this: ||| where the second choice becomes a nuisance for me is in the ||| case where one has thousands of clones and needs to keep track ||| of thousands of names in order to ensure that when the right one ||| has finished the right clone disappears. And I think it is a valid one. But is there anything else (execpt the issues that have to do with the fact tha ZFS lives in UNIX where fossil/venti in Plan9)? As for me, here's my wish list so far. It is all about fossil, since it looks like venti is quite fine (at least for my purposes) the way it is: 1. Block consistency. Yes I know the argument here is that you can always roll-back to the last known archival snapshot on venti. But the point is to kown *when* to roll back. And unless fossil warns you that a block has been corrupted you wouldn't know. 2. live mounting of arbitrary scores corresponding to vac VtRoot's to arbitrary sub-directories in my fossil tree. After all, if I can do create of regular files and sub-directories via fossil's console why can't I create pointers to the existing venti file-hierarchies? 3. Not sure whether this is a fossil requirement or not, but I feel uneasy that a root score is sort of unrecoverable from the pure venti archive. Its either that I know it or I don't. all this filesystem/snapshot/clone games are just a bunch of toys to make the admins happy and have little effective use for the end user. I disagree. Remember that this whole conversation started from a simple premise that a good archival system could be an efficient replacement for the SCM. If your end users are software developers -- that IS very relevant to them. It is actually quite remarkable how similar the models of fossil/venti and Git seem to be: both build on the notion of the immutable history. Both address the history by the hash index. Both have a mutable area whose only purpose is to stage data for the subsequent commit to the permanent history. Etc. I see what you mean, but in case of venti -- nothing disappears, really. From that perspective you can sort of make those zfs clones linger. The storage consumption won't be any different, right? the storage consumption should be the same, i presume. my problem is that in the case of zfs having several hundred snapshots significantly degrades the performance of the management tools to the extend that zfs list takes 30 seconds with about a thousand entries. Really?!? compared to fossil handling 5 years worth of daily dumps in less than a second. but that's not really a serious argument ;) And what's the output of term% ls -d path-to-your-fossil/archive/*/*/* | wc -l Great! I tired to do as much homework as possible (hence the delay) but I still have some questions left: 0. A dumb one: what's the proper way of cleanly shutting down fossil and venti? see fshalt. Hm. There doesn't seem to be much of shutdown code for fossil/venti in there. Does it mean that sync'ing venti and then just slay(1)'ing it is ok? Thanks, Roman.
Re: [9fans] Changelogs Patches?
On Fri, 2009-01-23 at 22:36 -0500, erik quanstrom wrote: You never know when end-to-end data consistency will start to really matter. Just the other day I attended the cloud conference where some Amazon EC2 customers were swapping stories of Amazon's networking stack malfunctioning and silently corrupting data that was written onto EBS. All of sudden, something like ZFS started to sound like a really good idea to them. i know we need to bow down before zfs's greatness, but i still have some questions. ☺ Oh, come on! I said something like ZFS ;-) These guys are on Linux, for crying out loud! They need to be saved one way or the other (and Solaris at least have *some* AMIs available on EC2). does ec2 corrupt all one's data en mass? From what I understood -- it was NOT en mass. But the scary thing is that they only noticed because of the dumb luck (the app coredumped because the input it was getting was not properly formatted or something) how do you do meaningful redundency in a cloud where one controls none of the failure-prone pieces. Well, that's the very point I'm trying to make: you have to be at least notified that your data got corrupted. Once you do get notified -- you can recover in variety of different ways: starting from simply re-uploading/re-generating your data all the way to the RAID-like things. finally, if p is the probability of a lost block, when does p become too large for zfs' redundency to overcome failures? It depends on the vdev configuration. You can do simple mirroring or you can do RAID-Z (which is more or less RAID-5 done properly). does this depend on the amount of i/o one does on the data or does zfs scrub at a minimum rate anyway. if it does, that would be expensive. You can do resilvering (fixing the data that is known to be bad) or scrubbing (verifying and fixing *all* the data). You also can configure things so that bad blocks either trigger or don't automatic resilvering. Does this answer your question? maybe ec2 is heads amazon wins, tails you loose? The scariest takeaway from the conference was: with the economy the way it is physical on-site datacenters are becoming a luxury for all but the most wealthy companies. Thus whether we like it or not virtual data centers are here to stay. Thanks, Roman.
Re: [9fans] Changelogs Patches?
On Tue, 2009-01-20 at 21:02 -0500, erik quanstrom wrote: In such a setup a corrupted block from a fossil partition will go undetected and could end up being stored in venti. At that point it will become venti problem. it's important to keep in mind that fossil is just a write buffer. it is not intended for the perminant storage of data. Sure. But it must store the data *intact* long enough for me to be able to do a snap. It has to be able to at least warn me about data corruption. while corrupt data could end up in venti, the exposure lies only between snapshots. you can rollback to the previous good score and continue. That is my *entire* point. If fossil doesn't tell you that the data in its buffer was/is corrupted -- you have no reason to rollback. Thanks, Roman.
Re: [9fans] Changelogs Patches?
On Wed, 2009-01-21 at 20:02 +0100, Uriel wrote: On Wed, Jan 21, 2009 at 2:43 AM, Roman V. Shaposhnik r...@sun.com wrote: Sure, but I can't really use venti without using fossil (again: we are talking about a typical setup here not something like vac/vacfs), can I? If I can NOT than fossil becomes a weak link that can let corrupted data go undetected all the way to a venti store. Fossil has always been a weak link, and probably will always be until somebody replaces it. There was some idea of replacing it with a version of ken's fs that uses a venti backend... Venti's rock solid design is the only thing that makes fossil minimally tolerable despite its usual tendency of stepping on its hair and falling on his face. After spending sometime reading the sources and grokking fossil I don't think it is a walking disaster. Far from it. There are a couple of places where things can be improved, to make *me* happier (YMMV), and I'll try to focus on these in replying to Andrei's email. Just to get some closure on this discussion. Thanks, Roman.
Re: [9fans] Changelogs Patches?
On Tue, 2009-01-20 at 09:19 -0500, erik quanstrom wrote: in the case of zfs, my claim is that since zfs can reuse blocks, two vdev backups, each with corruption or missing data in different places are pretty well useless. Got it. However, I'm still not fully convinced there's a definite edge one way or the other. Don't get me wrong: I'm not trying to defend ZFS (I don't think it needs defending, anyway) but rather I'm trying to test my mental model of how both work. if you end up rewriting a free block in zfs, there sure is. you can't decide which one is correct. You don't have to decide. You get use generation # for that. P.S. Oh, and in case of ZFS a damaged vdev will be detected (and possibly re-silvered) under normal working conditions, while fossil might not even notice a corruption. not true. one of many score checks: srv/lump.c:103: seterr(EStrange, lookuplump returned bad score %V not %V, u-score, score); I don't buy this argument for a simple reason: here's a very easy example that proves my point: term% fossil/fossil -f /tmp/fossil.bin fsys: dialing venti at net!$venti!venti warning: connecting to venti: Connection refused term% mount /srv/fossil /n/f term% cd /n/f/test term% echo 'this is innocent text' text.txt term% cat text.txt this is innocent text term% dd -if /dev/cons -of /tmp/fossil.bin -bs 1 -count 8 -oseek 278528 -trunc 0 this WAS 8+0 records in 8+0 records out term% rm /srv/fossil /srv/fscons term% fossil/fossil -f /tmp/fossil.bin fsys: dialing venti at net!$venti!venti warning: connecting to venti: Connection refused create /active/adm: file already exists create /active/adm adm sys d775: create /active/adm: file already exists create /active/adm/users: file already exists create /active/adm/users adm sys 664: create /active/adm/users: file already exists nuser 5 len 84 term% mount /srv/fossil /n/f2 term% cat /n/f2/test/text.txt this WAS innocent text term% Of course, with ZFS, the above corruption would be always noticed and sometimes (depending on your vdev setup) even silently fixed. Thanks, Roman.
