There's a big problem in your argument. You assume that when someone "buys a new system" they are getting all of the very newest hardware.
I venture to say I am not alone, in that when I upgrade, I always upgraded to hardware that was already out at least 6 months anyway (even when I ran windows), that is where the sweet spot is in price/performance ratio usually.
So, one could buy a new system every 6 months, with no driver hassles at all, if they just trail the market, like I'm sure millions do. (at least everyone who isn't rich and wants the most for their money).
What are you talking about? XFS is still being actively maintained. You can still grab 2.4.XX-XFS latest version of the kernel from their CVS, and it works like a charm.
In my recent dealings with SGI support, they were more than happy to help me with an IRIX/Linux interaction problem, and seemed to have a whole lot of Linux talent in-house.
I don't see any signs of SGI backing out of Linux, none at all.
I live in one of the pilot cable modem towns... Like the 4th nationwide to get cable modem service. I first used cable Internet around 1995, our high school got one.
They still have the ancient Zenith modems in service, and just a couple months ago started to move to DOCSIS.
The old modems had no rate limiting capabilities, so anyone could saturate the T1 they had to the Internet (it's a small town with not many geeks, so they can get by with a single tier 1 T1 and some peering T1s to their other locations nearby).
Anyway, they talked about migration to DOCSIS for the last 3 years, and they are just getting around to it. Cable modem companies are really resistant to changing the customer hardware.
One good think about those old Zenith modems though, was they were like an ethernet hub, you could see the activity and collisions on the cable side. That also gave away their secret that the collision light stayed on without flickering at all from 10:30 am until 8pm.
Somehow you could still pull down around 30KB/sec every now and then. After P2P came to town, it got a lot worse though.
Re:Waaah!!! it's a kernel patch Waaaahhh!!!
on
Kernel 2.5.3 Released
·
· Score: 3, Insightful
Well, this is a Linux News site, whether anyone wants to deny that or not.
But anyway, it might be better if they put kernel releases into their own topic, so people could exclude it, at least it would limit bitching, and only take 5 minutes to implement.
You know, the kernel.org guys never claimed cash flow problems, they just wanted another "main site" mirror for redundancy.
After the outage when/. ran the story, everyone just ASS-U-ME ed that it was cash flow problems, when the LKML archive clearly shows it was just technical difficulties.
That said, people should be getting diffs when they can anyway, there is no point in wasting bandwidth.
OK, experiment time, you stand at the bottom of a 50 story building and I will drop a 100 pound relatively aerodynamic ball of metal on you. We'll see how that goes.
I had the same experience, with hardware incompatibilities and recalls. I think 3ware has it worked out now though, and I am happy with the end result, even though the project was severly delayed due to 3ware.
We used this case. You can put blocks in that allow you to install three 3.5 inch drives into two 5.25 slots, with a cooling fan, so this case holds something like 40 disks. It has two sets of two redundant power supplies available too, and room for two motherboards. It costs about $800.
It's i960 based, so write speeds are going to be a lot slower than software RAID5.
Also, you can't really put more than one SX6000 in a single system, that sort of hampers scalibility.
Still, if you wanted 1TB, it might be a good option, so long as you don't care too much about write speeds, or you use it in JBOD mode with software RAID.
In case you didn't notice, it's RAID5. One hard disk could go bad with no issues other than slowdown.
They could also do what we did with our IDE TB. We used three RAID5s in hardware, each with hot swap. In theory, if they failed just right, we could lose up to 6 drives without losing any data.
The three RAID5s are hardware RAID0ed together. The worst case scenerio is a simultaneous failure of two drives on the same array. But we saved so much money using IDE that we just built two complete systems for less price than SCSI. So really, we would have to hit the worst case scenerio twice at nearly the same time to have a total loss.. It gets less and less likely.
We're using rsync over ssh... These IDE TB's were so cheap, we just built two for redundancy. Every night the second one backs up the first one.
We still have a tape robot, but we will only be backing up the most critical of data, our tape robot is only 1.2TB and cost many times what the TB RAIDs did.
Well I know you might have just been oversimplifying for the benefit of the less informed, but they aren't really rounding.
In the SI system, mega means million, kilo means thousand, not 1024 for kilo and 1024^2 for mega like computer geeks use it to mean. The hard disk manufacturers are just using the terms more correctly, because it is to their advantage.
I'm sure almost everyone is familiar with Mebi and Tibi now, so I won't go into all that.
Inspired by Slashdot's earlier story that was nearly identical, and with the help of Peter Ashford from ACCS, we built two servers, both with capacities well over a TB, for around $8000 each. They have the capacity to expand to 3TB if need be.
As far as performance:
(from my memory)
EXT3: About 16MB/Sec block write, 45MB/sec block read
ReiserFS: About 20MB/sec block write, 130MB/Sec block read (that's no typo).
XFS: About 30MB/sec block write, 85MB/sec block read.
It seems that file system plays a large role in performance. The arrays are three RAID5 in hardware using Linux software RAID0 on top of the RAID5 arrays to tie them together.
IDE RAID controllers are 3ware Escalade 7810. Write performance can be greatly increased by using 7850 cards that have more cache.
We stuck with XFS, Reiserfs had a bigfile bug, files created over 2GB would lock up the computer basically. XFS in general seemed much more mature, reiserfs seems more like someone's college thesis project, that they never cleaned up to be production grade.
We experimented with different RAID0 stripe sizes, the hardware RAID5 stripe size is fixed at 64k, there are 7 active disks in each array and one hot spare. Stripe size tweaking seemed to mostly trade off read for write speed, within a certain range of values, with a taper off in performance at either extreme, (down around 8k stripes, or over 1024k stripes)
We eventually went with 1024k stripes. That is what the benchmarks above reflect. The variance in file system performance could very well be due to interactions with stripe size, but there seemed to be common themes (reiser always read fastest no matter what stripe, XFS was always better at writes)
I have been in so many arguments with SCSI zealots on here over this RAID... I wish people would understand what price/performance ratio means. IDE isn't a superior technology, but every now and then, it is the right tool for the job, when price is a goal too.
Slashdot Mirror
or even scp for that matter...
There's a big problem in your argument. You assume that when someone "buys a new system" they are getting all of the very newest hardware.
I venture to say I am not alone, in that when I upgrade, I always upgraded to hardware that was already out at least 6 months anyway (even when I ran windows), that is where the sweet spot is in price/performance ratio usually.
So, one could buy a new system every 6 months, with no driver hassles at all, if they just trail the market, like I'm sure millions do. (at least everyone who isn't rich and wants the most for their money).
MCA was not proprietary, neither was the PS/2 mouse interface. The keyboard interface was exactly the same, with a smaller connector.
MCA didn't catch on as an accepted standard, but that doesn't mean it wasn't released as one.
What are you talking about? XFS is still being actively maintained. You can still grab 2.4.XX-XFS latest version of the kernel from their CVS, and it works like a charm.
In my recent dealings with SGI support, they were more than happy to help me with an IRIX/Linux interaction problem, and seemed to have a whole lot of Linux talent in-house.
I don't see any signs of SGI backing out of Linux, none at all.
I've been the gaming console running Linux several times in the past at other shows (most notably LinuxWorld in Tokyo)
How many Mhz do you run at?
Sell them on ebay, starting now, and then in a few weeks, buy some more. You should be able to make some money off of the temporary surge in demand.
Imagine a beowulf clus.....
Oh nevermind.
Man... The NSA really really wants to be able to brute force our strongest keys fast. Any estimates on the price of this thing?
Yeah, you're telling me.
You got them pegged.
I live in one of the pilot cable modem towns... Like the 4th nationwide to get cable modem service. I first used cable Internet around 1995, our high school got one.
They still have the ancient Zenith modems in service, and just a couple months ago started to move to DOCSIS.
The old modems had no rate limiting capabilities, so anyone could saturate the T1 they had to the Internet (it's a small town with not many geeks, so they can get by with a single tier 1 T1 and some peering T1s to their other locations nearby).
Anyway, they talked about migration to DOCSIS for the last 3 years, and they are just getting around to it. Cable modem companies are really resistant to changing the customer hardware.
One good think about those old Zenith modems though, was they were like an ethernet hub, you could see the activity and collisions on the cable side. That also gave away their secret that the collision light stayed on without flickering at all from 10:30 am until 8pm.
Somehow you could still pull down around 30KB/sec every now and then. After P2P came to town, it got a lot worse though.
Well, this is a Linux News site, whether anyone wants to deny that or not.
But anyway, it might be better if they put kernel releases into their own topic, so people could exclude it, at least it would limit bitching, and only take 5 minutes to implement.
You know, the kernel.org guys never claimed cash flow problems, they just wanted another "main site" mirror for redundancy.
/. ran the story, everyone just ASS-U-ME ed that it was cash flow problems, when the LKML archive clearly shows it was just technical difficulties.
After the outage when
That said, people should be getting diffs when they can anyway, there is no point in wasting bandwidth.
Yeah, and maybe we could get some lions and Christians, and we would really be set!
I'm surprised no one has though of this before!
</sarcasm>
Uhh, by the time our letters got there, it would be nearly a week from now. Pretty useless to write them snail mail and ask that.
OK, experiment time, you stand at the bottom of a 50 story building and I will drop a 100 pound relatively aerodynamic ball of metal on you. We'll see how that goes.
I had the same experience, with hardware incompatibilities and recalls. I think 3ware has it worked out now though, and I am happy with the end result, even though the project was severly delayed due to 3ware.
We are actually addressing that. We plan to eventually send one of the servers off-site to our other location in a different state.
Here is your case
We used this case. You can put blocks in that allow you to install three 3.5 inch drives into two 5.25 slots, with a cooling fan, so this case holds something like 40 disks. It has two sets of two redundant power supplies available too, and room for two motherboards. It costs about $800.
$600 will not buy you a system to support a TB RAID.
I've actually designed one of these, and it's a little more involved than you might think.
It's i960 based, so write speeds are going to be a lot slower than software RAID5.
Also, you can't really put more than one SX6000 in a single system, that sort of hampers scalibility.
Still, if you wanted 1TB, it might be a good option, so long as you don't care too much about write speeds, or you use it in JBOD mode with software RAID.
In case you didn't notice, it's RAID5. One hard disk could go bad with no issues other than slowdown.
They could also do what we did with our IDE TB. We used three RAID5s in hardware, each with hot swap. In theory, if they failed just right, we could lose up to 6 drives without losing any data.
The three RAID5s are hardware RAID0ed together. The worst case scenerio is a simultaneous failure of two drives on the same array. But we saved so much money using IDE that we just built two complete systems for less price than SCSI. So really, we would have to hit the worst case scenerio twice at nearly the same time to have a total loss.. It gets less and less likely.
We're using rsync over ssh... These IDE TB's were so cheap, we just built two for redundancy. Every night the second one backs up the first one.
We still have a tape robot, but we will only be backing up the most critical of data, our tape robot is only 1.2TB and cost many times what the TB RAIDs did.
Well I know you might have just been oversimplifying for the benefit of the less informed, but they aren't really rounding.
In the SI system, mega means million, kilo means thousand, not 1024 for kilo and 1024^2 for mega like computer geeks use it to mean. The hard disk manufacturers are just using the terms more correctly, because it is to their advantage.
I'm sure almost everyone is familiar with Mebi and Tibi now, so I won't go into all that.
Inspired by Slashdot's earlier story that was nearly identical, and with the help of Peter Ashford from ACCS, we built two servers, both with capacities well over a TB, for around $8000 each. They have the capacity to expand to 3TB if need be.
Story here
As far as performance:
(from my memory)
EXT3: About 16MB/Sec block write, 45MB/sec block read
ReiserFS: About 20MB/sec block write, 130MB/Sec block read (that's no typo).
XFS: About 30MB/sec block write, 85MB/sec block read.
It seems that file system plays a large role in performance. The arrays are three RAID5 in hardware using Linux software RAID0 on top of the RAID5 arrays to tie them together.
IDE RAID controllers are 3ware Escalade 7810. Write performance can be greatly increased by using 7850 cards that have more cache.
We stuck with XFS, Reiserfs had a bigfile bug, files created over 2GB would lock up the computer basically. XFS in general seemed much more mature, reiserfs seems more like someone's college thesis project, that they never cleaned up to be production grade.
We experimented with different RAID0 stripe sizes, the hardware RAID5 stripe size is fixed at 64k, there are 7 active disks in each array and one hot spare. Stripe size tweaking seemed to mostly trade off read for write speed, within a certain range of values, with a taper off in performance at either extreme, (down around 8k stripes, or over 1024k stripes)
We eventually went with 1024k stripes. That is what the benchmarks above reflect. The variance in file system performance could very well be due to interactions with stripe size, but there seemed to be common themes (reiser always read fastest no matter what stripe, XFS was always better at writes)
I have been in so many arguments with SCSI zealots on here over this RAID... I wish people would understand what price/performance ratio means. IDE isn't a superior technology, but every now and then, it is the right tool for the job, when price is a goal too.
It's still there, keep your pants on. Just remember to take out the space that Slashcode puts in the URL to prevent page widening posts.
Yeah, you are probably right, mine was just a rough estimate, only off by a single constant multiplier. :)
That settlement has nothing to do with this case.