yeah, and how to keep that all cool? They had problems cooling 24 processors/rack. I have to imagine 80 processors/rack will be quite the beast to keep cool. Even if you don't water cool right to the CPU, at this density you basically have to run chilled-water pipes right up to the rack and have a big chiller-radiator under each rack.
I'm not saying it's a bad idea, but it's not free, and a lot of people forget this cost when they throw around cost estimates for clusters.
what you're proposing is probably a poor solution to your needs. To use RAID-like disk storage across the network will require several high-latency transfers across the network for every write opperation. -very slow.
Furthermore, every time one of the computers is powered off the system will wait for that machine to come back, or will treat it like a dead disk. Even with high performance raid devices, degraded mode is mighty slow. Then when the device comes back you will have to rebuild the raid. A long/slow/agonizing process even with fast hardware.
I think rsync in a cron tab is a much better idea.
So then, who really cares if the athlon64 is X% faster at this task or Y% slower at that task, when compared to the latest apple. The point remains that X and Y are not 250. If you sat down at one and ran photoshop you would not go to the other and think "wow this is really slow". You'd have to sit there with your stop-watch to see if one or the other was faster.
No one switches to Apple because they are faster than AMD/intel. Similarly noone switches the other direction because of speed. You switch (or continue using whatever you're using) because you enjoy the environment, or because you are impressed by the general look and feel, or because all your friends use a (foo) and you want to use a (foo) too.
The cool thing about both the athlon64 is that it's noticably faster than the duron under my desk, and I can run the same software. The cool thing about the G5 is that it's noticably faster than the G4 under my buddy's desk, and he can run the same software he already uses. They are both really nice advances, and to compare the two is stupid. Even if the athlon64 was 85% faster than the G5 at every task my buddy still wouldn't buy one. My evidence: My Xeon 2.4 IS 85% faster than the 500Mhz G4 he has now, but he still uses the mac.
Aside from that, compare $3500 machines is great for the "my mac penis is bigger than your amd penis" crowd, but for those of us who want to spend $1000 for a computer, it's still athlons, celerons, and iBooks. In the grand scheme of things a comparison of consumer-priced systems is far, far more interesting, as the volume is much, much higher. When 64-bit athlons and G5s make their way into inexpensive desktops and laptops, then lets all get worked up about it.
sounds like it might make a very nice DSP chip. However lots of simple, non-contentious, non-overlapping floatingpoint computation is really not a problem most desktop or notebook users are struggling with. In fact it's really not a problem that super-computers are struggling with. There have been pci cards with power-pc chips on them for years. Curiously enough these cards haven't ended up being used in many top500 supercomputers.
A fast low-voltage DSP chip is interesting for a lot of applications, but not in the way that this press release describes the product.
10-20 TB is likely accurate for the first phase deployment. This isn't CERN's big guns, as the product has just been deployed. Warry customers are not going to bet the boat on something untried. Besides that, the 10-20TB is no doubt the on-disk storage, with more backed by tape in the future. (assuming IBM gets the HSM stuff working correctly in the near term). Hell I've got 10TB of tape under my desk.
What's interesting about storage tank is that it's a general purpose cluster file system, unlike lustre and GPFS which are both heaviliy concentrated on working sets in hpc clusters. While they are not suited to long-term datacenter storage, systems like storage tank (and competing products from adic, sgi, sistina, veritas) support the heirachical storage, security, and disaster-recovery of more general data needs.
So the author's point is that linux crunchies shouldn't discount SCO group's chances of winning in court. Why? What are the real repurcushions if they do win? IBM will have to pay them some ammount of money, as determined by the court. Maybe, MAYBE, some small piece of code will need to be clean-room re-written. IBM should care, definately. But we crunchies can watch from a distance and ignore it for the most part.
The author does make a good point that all sorts of prattle thrown about on/. or on ESR's blog don't mean jack in a court of law. But in the end, so what?
But $100,000 to get access to 133 communications protocols doesn't sound all that expensive. What does an intel P4 bus license cost? How much would you expect to pay to get access to someone else's engineering work. Any company that's going to try to make a MS compatible network product of some sort is going to spend many multiples of this number on the engineering effort for even a trivial product. M$ has some pretty aweful marketing practices and gross business practices, but this is far from the worst. This doesn't seem out of line with the costs to license other proprietary technology in the marketplace.
Everyone and their mother seems to be hollering about how desperate sun is, and how they're going to go the way of the dodo bird. While there is probably a kernel of truth to this, the same desperation is wide-spread throughout the IT industry. Times of economic hardship provide a bit of capitalist natural selection. They force companies to creatively adapt and struggle to survive. Some don't.
However, Sun is a very large beast, and one that has survived previous hardship, and created really compelling technology over the years. Sun long held to the single system mantra of sparc everywhere, and was often criticized for doing so. Now those same critics, for love of hearing their own voices, are ballyhooing the move toward intel chips and linux.
Lets face it, sun would be happy to take your money no matter what you're looking to run, and if they can offer a product line and make money selling it, they will do so. Go to IBM's page and see how many server platforms they offer: x86, AS/400, Z-series, RS/6000, windows, linux, aix, Z/OS, OS/400, they can sell you products across the entire span of server systems, and Sun can do that too. Sun sells 2 hardware platforms, and 2 operating systems, both of which run on both processor types. Sun doesn't win or lose because their x86 sled is 3% cheaper of 2% faster than dell's models. They win or lose because the servers are down 4 hours a year instead of 8 days. They win or lose because they sell edge servers and database servers and storage systems, with tape archives, network connectivity, SANs, middle-ware, applications, and peace-of-mind.
While I'm not willing to predict Sun's return to dominance in the event of an IT spending reprive, I think those sounding the death knell might have to wait a while. Making the argument that x86+linux is cheaper than sparc+solaris just isn't the right argument to make. cheap + fast are NOT the only elements of computer using/buying/selling that Sun needs to consider.
While SGIs are almost exclussively used for High performance / technical computing, and not typical datacenter uses, that is for software reasons, not hardware. The Irix operating system has always been more concerned with scalability and performance than with stability, which did a good job of excluding them from the early web serving and a lot of database work, which was then taken over by IBM, HP, SUN, and more recently by linux.
This rack is not, in fact, going to knock out your cooling / power system worse than a typical rack. 128 processors x 17 watts is 2176watts, plus some extra for routers, etc. This pales to what a lot of data centers are doing with racks of dual P4, linux boxes at up to 6400 watts per rack. That is one of the (few) selling points of the MIPS processor. They don't push up the processor speeds like intel has been doing, but they are nice and cool.
Don't get me wrong, I'm no huge fan of SGI supercomputers, but they are a lot more easily deployed than say a NEC or a CRAY vector machine.
I suppose I'm not surprised that the OSS solution was not appropriate to your needs. OSS can only solve so many problems. Any time custom engineering is required, things get expensive quickly. If there is a commercial software package that already does what you need to do, and there's no single OSS solution that does every thing as you need it, the likely case is that the OSS will cost much more to use over time. IF this were not true, there would be no more closed source software companies.
Open source software is software like software developed under any sort of model, and it is true for all software that good software does not necessarily make for a good product. Documentation, support, longevity are things to be considered when making any software decision.
Look at the Open source software that is being widely deployed in the server industry: it is long-lived, tried, and tested stuff. It is the sort of open source software that IBM is willing to stand behind, and sell a support contract for. This is the sort of support you can by. IBM (and the like) will sell you support for the open source software that they think is robust enough for them to support.
I doubt very much there is much of a market for someone to sell wide-reaching OSS support. Support services are very expensive operations to run, and the profit margins are not tremendously high. The only way to make much money at it is to have a very small niche, in which there are few things to go wrong, and a small team of engineers can handle all of the support calls, or to do it on a very large scale, and profit by selling huge contracts. Otherwise the capital needed to develop procedures, expertiece, and to keep around a capable staff just don't pay off in the end.
OSS is no magic bullet. There's some open source software I'd deploy in the field, but a whole lot that I tinker with and wouldn't dare install on a critical server.
While it's all well and good to say that the taxpayers funded the research, thus we should get the code for free (bsd or gpl, whatever), it is often not realistic. Taxpayer dollars do not go into, nor does research come out of some big ethereal blob of government. Whatever research lab did the work is granted a finite budget by some oversight committee, and must continually lobby to have that budget renewed.
There is never enough money to go around, even in government funded research labs, and one way to recoupe some of the costs of doing research is selling the rights to the research. Think Velcro, think foam beds that mold to your body, think NCSA mosaic. While we can (and should) get mad that some corporations are able to get this research for little or nothing by way of graft and pork-barrel politics, the idea is intrinsically sound. If the government has done the research, and selling the research allows that group to continue development with less cost to the taxpayer, why not? Research groups can release their code under commercial agreements while it is profitable to do so, and should release their code under a totally-free license like BSD when selling the code is not prudent.
While I would like to see government software research made publically available (as much has), the GPL is not necissarily the vehicle for such action. If a goverment lab releases code under the GPL, it should be sure that 1) they are in a situation where they can substantially direct the future development of the software as a GPL project 2) they will never need to be in step with the GPLed version of the code, and can continue to develop along their own path, independant of the direction JoeBlowProgrammer decides to take the code. 3) the lab will always be able to use the GPL version of the code, and will always be able to release their future changes under the GPL.
Otherwise the lab can end up screwing itself with the viral nature of the GPL.
Chess cannot be completely solved by brute force, not unless it's a lot of brute force. The difficulty of chess comes from anticipating moves that will happen any number of moves in the future. This sort of computation grows logarithmically more difficult with the number of moves. Furthermore it must anticipate the opponent's moves.
Chess requires sacrifice, a difficult concept to use in a raw computational method. The set of "rules" for each computational step is dependant on all preceding steps. While this play tree is evaluated (depth first or breadth first) some measure of "goodness" must be evaluated for all future board positions. They must be stored and compared. A brute force evaluation must assess the likelyhood that any future board position will lead to other favorable board positions further into the game. I'm sure that very good chess simulators are very aware of strategies and methods that tallented chess players are aware of. If it were just a brute force method, they'd be running deap fritz on a thousand processor monster.
Go is a difficult and interesting problem also, yet the fundamental problems are similar. (How to define and compare the relative "goodness" of future possible boards, how to elinimiate unnessesary computation, how to store previously made calculations and search them effectively.) The higher number of board positions just makes it all that much harder.
Beowulf and similar clusters have hugely lowered the cost of super-computing for a great number of scientific problems. Due to the great interdependance of data and the relative high latency of cluster interconnects, some problems are not easily worked on using clusters. What are the evolving areas of clustered computing? Where are the advances: Are new algorithms being developed for these difficult problems, or are clusters becoming more capable?
- Also -
What tools are seriously lacking in linux clusters? Are open source (or low cost) cluster filesystems necessary to expand the use of beowulf clusters? - Are better libraries needed? Where is research needed?
Of course iSCSI is not ready for prime time. There are only a few HBAs available and no native iSCSI RAIDs / Disks. However, it will all likely come together very quickly.
All of the problems you site are not intrinsic characteristics of iSCSI. Simply put iSCSI IS A SAN, just like Fibre Channel IS A SAN. The transport protocol, frame size, management systems differ, but they both offer the same fundamental capabilities. They are both switched networks over which an embeded SCSI-like protocol is transfered between hosts and disks. Both allow multiple paths for higher bandwidth. both allow "zoning". both allow redundancy, and geographical separation.
The lower cost of iSCSI is attractive, while the somewhat lower performance is frustrating. But the killer advantage that iSCSI has over FC is the increadable number of network administrators qualified to run an ip-based network. Hardware costs are not the only costs associated with running a computer system.
The more important point is that even if it IS an infringement of the GPL, it is in our best interest to let them do it. Corel, as a major software player can't afford to publicly release a beta version of their distribution. If they do, PCweek or some other bottom-feeding computer magazine is gonna through it on a lab box, test it, and tell the world that the product is crap. No one will buy it then. Corel isn't making a distribution for us, they're making it to sell to corps who would not otherwise use linux. I say give them the benefit of the doubt and let them fool around for a while. Hell, everything in there that is GPLd is probably debian anyway. The value added stuff is probably not.
And all cars should be made to get 45 mpg while travelling at 150 mph without any interface of the driver. --- Yes, wouldn't that all be keen. Who wants to write it? you? From what I hear GFS has some of these capabilities, but last time I looked at the source, it didn't yet have journaling, which you almost need on a truly distributed file system. As a local file system, though, it ran almost twice as fast as ext2.
Oh, just shut up. Beowulf this and beowulf that. Beowulf is just PVM and MPI on top of linux. It i`s only usefull on "embarassingly parallelizable" computations. It is completely of no use to linux users, whos main problems are solved with apache, emacs, and wordperfect. If you don't already own an SP1, challenge, or origin, you probably have no use of a beowulf cluster.
Slashdot Mirror
yeah, and how to keep that all cool? They had problems cooling 24 processors/rack. I have to imagine 80 processors/rack will be quite the beast to keep cool. Even if you don't water cool right to the CPU, at this density you basically have to run chilled-water pipes right up to the rack and have a big chiller-radiator under each rack.
I'm not saying it's a bad idea, but it's not free, and a lot of people forget this cost when they throw around cost estimates for clusters.
what you're proposing is probably a poor solution to your needs. To use RAID-like disk storage across the network will require several high-latency transfers across the network for every write opperation. -very slow.
Furthermore, every time one of the computers is powered off the system will wait for that machine to come back, or will treat it like a dead disk. Even with high performance raid devices, degraded mode is mighty slow. Then when the device comes back you will have to rebuild the raid. A long/slow/agonizing process even with fast hardware.
I think rsync in a cron tab is a much better idea.
So then, who really cares if the athlon64 is X% faster at this task or Y% slower at that task, when compared to the latest apple. The point remains that X and Y are not 250. If you sat down at one and ran photoshop you would not go to the other and think "wow this is really slow". You'd have to sit there with your stop-watch to see if one or the other was faster.
No one switches to Apple because they are faster than AMD/intel. Similarly noone switches the other direction because of speed. You switch (or continue using whatever you're using) because you enjoy the environment, or because you are impressed by the general look and feel, or because all your friends use a (foo) and you want to use a (foo) too.
The cool thing about both the athlon64 is that it's noticably faster than the duron under my desk, and I can run the same software. The cool thing about the G5 is that it's noticably faster than the G4 under my buddy's desk, and he can run the same software he already uses. They are both really nice advances, and to compare the two is stupid. Even if the athlon64 was 85% faster than the G5 at every task my buddy still wouldn't buy one. My evidence: My Xeon 2.4 IS 85% faster than the 500Mhz G4 he has now, but he still uses the mac.
Aside from that, compare $3500 machines is great for the "my mac penis is bigger than your amd penis" crowd, but for those of us who want to spend $1000 for a computer, it's still athlons, celerons, and iBooks. In the grand scheme of things a comparison of consumer-priced systems is far, far more interesting, as the volume is much, much higher. When 64-bit athlons and G5s make their way into inexpensive desktops and laptops, then lets all get worked up about it.
sounds like it might make a very nice DSP chip. However lots of simple, non-contentious, non-overlapping floatingpoint computation is really not a problem most desktop or notebook users are struggling with. In fact it's really not a problem that super-computers are struggling with. There have been pci cards with power-pc chips on them for years. Curiously enough these cards haven't ended up being used in many top500 supercomputers.
A fast low-voltage DSP chip is interesting for a lot of applications, but not in the way that this press release describes the product.
10-20 TB is likely accurate for the first phase deployment. This isn't CERN's big guns, as the product has just been deployed. Warry customers are not going to bet the boat on something untried. Besides that, the 10-20TB is no doubt the on-disk storage, with more backed by tape in the future. (assuming IBM gets the HSM stuff working correctly in the near term). Hell I've got 10TB of tape under my desk.
What's interesting about storage tank is that it's a general purpose cluster file system, unlike lustre and GPFS which are both heaviliy concentrated on working sets in hpc clusters. While they are not suited to long-term datacenter storage, systems like storage tank (and competing products from adic, sgi, sistina, veritas) support the heirachical storage, security, and disaster-recovery of more general data needs.
Seems like a desktop display would be a good place to release this technology first.
So the author's point is that linux crunchies shouldn't discount SCO group's chances of winning in court. Why? What are the real repurcushions if they do win? IBM will have to pay them some ammount of money, as determined by the court. Maybe, MAYBE, some small piece of code will need to be clean-room re-written. IBM should care, definately. But we crunchies can watch from a distance and ignore it for the most part.
/. or on ESR's blog don't mean jack in a court of law. But in the end, so what?
The author does make a good point that all sorts of prattle thrown about on
But $100,000 to get access to 133 communications protocols doesn't sound all that expensive. What does an intel P4 bus license cost? How much would you expect to pay to get access to someone else's engineering work.
Any company that's going to try to make a MS compatible network product of some sort is going to spend many multiples of this number on the engineering effort for even a trivial product. M$ has some pretty aweful marketing practices and gross business practices, but this is far from the worst. This doesn't seem out of line with the costs to license other proprietary technology in the marketplace.
Everyone and their mother seems to be hollering about how desperate sun is, and how they're going to go the way of the dodo bird. While there is probably a kernel of truth to this, the same desperation is wide-spread throughout the IT industry. Times of economic hardship provide a bit of capitalist natural selection. They force companies to creatively adapt and struggle to survive. Some don't.
However, Sun is a very large beast, and one that has survived previous hardship, and created really compelling technology over the years. Sun long held to the single system mantra of sparc everywhere, and was often criticized for doing so. Now those same critics, for love of hearing their own voices, are ballyhooing the move toward intel chips and linux.
Lets face it, sun would be happy to take your money no matter what you're looking to run, and if they can offer a product line and make money selling it, they will do so. Go to IBM's page and see how many server platforms they offer: x86, AS/400, Z-series, RS/6000, windows, linux, aix, Z/OS, OS/400, they can sell you products across the entire span of server systems, and Sun can do that too. Sun sells 2 hardware platforms, and 2 operating systems, both of which run on both processor types. Sun doesn't win or lose because their x86 sled is 3% cheaper of 2% faster than dell's models. They win or lose because the servers are down 4 hours a year instead of 8 days. They win or lose because they sell edge servers and database servers and storage systems, with tape archives, network connectivity, SANs, middle-ware, applications, and peace-of-mind.
While I'm not willing to predict Sun's return to dominance in the event of an IT spending reprive, I think those sounding the death knell might have to wait a while. Making the argument that x86+linux is cheaper than sparc+solaris just isn't the right argument to make. cheap + fast are NOT the only elements of computer using/buying/selling that Sun needs to consider.
While SGIs are almost exclussively used for High performance / technical computing, and not typical datacenter uses, that is for software reasons, not hardware. The Irix operating system has always been more concerned with scalability and performance than with stability, which did a good job of excluding them from the early web serving and a lot of database work, which was then taken over by IBM, HP, SUN, and more recently by linux.
This rack is not, in fact, going to knock out your cooling / power system worse than a typical rack. 128 processors x 17 watts is 2176watts, plus some extra for routers, etc. This pales to what a lot of data centers are doing with racks of dual P4, linux boxes at up to 6400 watts per rack. That is one of the (few) selling points of the MIPS processor. They don't push up the processor speeds like intel has been doing, but they are nice and cool.
Don't get me wrong, I'm no huge fan of SGI supercomputers, but they are a lot more easily deployed than say a NEC or a CRAY vector machine.
I suppose I'm not surprised that the OSS solution was not appropriate to your needs. OSS can only solve so many problems. Any time custom engineering is required, things get expensive quickly. If there is a commercial software package that already does what you need to do, and there's no single OSS solution that does every thing as you need it, the likely case is that the OSS will cost much more to use over time. IF this were not true, there would be no more closed source software companies.
Open source software is software like software developed under any sort of model, and it is true for all software that good software does not necessarily make for a good product. Documentation, support, longevity are things to be considered when making any software decision.
Look at the Open source software that is being widely deployed in the server industry: it is long-lived, tried, and tested stuff. It is the sort of open source software that IBM is willing to stand behind, and sell a support contract for. This is the sort of support you can by. IBM (and the like) will sell you support for the open source software that they think is robust enough for them to support.
I doubt very much there is much of a market for someone to sell wide-reaching OSS support. Support services are very expensive operations to run, and the profit margins are not tremendously high. The only way to make much money at it is to have a very small niche, in which there are few things to go wrong, and a small team of engineers can handle all of the support calls, or to do it on a very large scale, and profit by selling huge contracts. Otherwise the capital needed to develop procedures, expertiece, and to keep around a capable staff just don't pay off in the end.
OSS is no magic bullet. There's some open source software I'd deploy in the field, but a whole lot that I tinker with and wouldn't dare install on a critical server.
While it's all well and good to say that the taxpayers funded the research, thus we should get the code for free (bsd or gpl, whatever), it is often not realistic. Taxpayer dollars do not go into, nor does research come out of some big ethereal blob of government. Whatever research lab did the work is granted a finite budget by some oversight committee, and must continually lobby to have that budget renewed.
There is never enough money to go around, even in government funded research labs, and one way to recoupe some of the costs of doing research is selling the rights to the research. Think Velcro, think foam beds that mold to your body, think NCSA mosaic. While we can (and should) get mad that some corporations are able to get this research for little or nothing by way of graft and pork-barrel politics, the idea is intrinsically sound. If the government has done the research, and selling the research allows that group to continue development with less cost to the taxpayer, why not? Research groups can release their code under commercial agreements while it is profitable to do so, and should release their code under a totally-free license like BSD when selling the code is not prudent.
While I would like to see government software research made publically available (as much has), the GPL is not necissarily the vehicle for such action. If a goverment lab releases code under the GPL, it should be sure that
1) they are in a situation where they can substantially direct the future development of the software as a GPL project
2) they will never need to be in step with the GPLed version of the code, and can continue to develop along their own path, independant of the direction JoeBlowProgrammer decides to take the code.
3) the lab will always be able to use the GPL version of the code, and will always be able to release their future changes under the GPL.
Otherwise the lab can end up screwing itself with the viral nature of the GPL.
Chess cannot be completely solved by brute force, not unless it's a lot of brute force. The difficulty of chess comes from anticipating moves that will happen any number of moves in the future. This sort of computation grows logarithmically more difficult with the number of moves. Furthermore it must anticipate the opponent's moves.
Chess requires sacrifice, a difficult concept to use in a raw computational method. The set of "rules" for each computational step is dependant on all preceding steps. While this play tree is evaluated (depth first or breadth first) some measure of "goodness" must be evaluated for all future board positions. They must be stored and compared. A brute force evaluation must assess the likelyhood that any future board position will lead to other favorable board positions further into the game. I'm sure that very good chess simulators are very aware of strategies and methods that tallented chess players are aware of. If it were just a brute force method, they'd be running deap fritz on a thousand processor monster.
Go is a difficult and interesting problem also, yet the fundamental problems are similar. (How to define and compare the relative "goodness" of future possible boards, how to elinimiate unnessesary computation, how to store previously made calculations and search them effectively.) The higher number of board positions just makes it all that much harder.
Beowulf and similar clusters have hugely lowered the cost of super-computing for a great number of scientific problems. Due to the great interdependance of data and the relative high latency of cluster interconnects, some problems are not easily worked on using clusters. What are the evolving areas of clustered computing? Where are the advances: Are new algorithms being developed for these difficult problems, or are clusters becoming more capable?
- Also -
What tools are seriously lacking in linux clusters? Are open source (or low cost) cluster filesystems necessary to expand the use of beowulf clusters? - Are better libraries needed? Where is research needed?
Of course iSCSI is not ready for prime time. There are only a few HBAs available and no native iSCSI RAIDs / Disks. However, it will all likely come together very quickly.
All of the problems you site are not intrinsic characteristics of iSCSI. Simply put iSCSI IS A SAN, just like Fibre Channel IS A SAN. The transport protocol, frame size, management systems differ, but they both offer the same fundamental capabilities. They are both switched networks over which an embeded SCSI-like protocol is transfered between hosts and disks. Both allow multiple paths for higher bandwidth. both allow "zoning". both allow redundancy, and geographical separation.
The lower cost of iSCSI is attractive, while the somewhat lower performance is frustrating. But the killer advantage that iSCSI has over FC is the increadable number of network administrators qualified to run an ip-based network. Hardware costs are not the only costs associated with running a computer system.
The more important point is that even if it IS an infringement of the GPL, it is in our best interest to let them do it. Corel, as a major software player can't afford to publicly release a beta version of their distribution. If they do, PCweek or some other bottom-feeding computer magazine is gonna through it on a lab box, test it, and tell the world that the product is crap. No one will buy it then.
Corel isn't making a distribution for us, they're making it to sell to corps who would not otherwise use linux. I say give them the benefit of the doubt and let them fool around for a while. Hell, everything in there that is GPLd is probably debian anyway. The value added stuff is probably not.
And all cars should be made to get 45 mpg while travelling at 150 mph without any interface of the driver. --- Yes, wouldn't that all be keen. Who wants to write it? you? From what I hear GFS has some of these capabilities, but last time I looked at the source, it didn't yet have journaling, which you almost need on a truly distributed file system. As a local file system, though, it ran almost twice as fast as ext2.
Oh, just shut up.
Beowulf this and beowulf that. Beowulf is just PVM and MPI on top of linux. It i`s only usefull on "embarassingly parallelizable" computations. It is completely of no use to linux users, whos main problems are solved with apache, emacs, and wordperfect. If you don't already own an SP1, challenge, or origin, you probably have no use of a beowulf cluster.